Opp,s sorry, forgot to specify it in my previous mail, I snipped it to move
it but forgot to paste it back in.
64 bit time values for NT/SMB time values (and I think DCERPC use the
identical representation)
it to specify times a signed 64 bit integer.
Positive values for this integer means number of quantas passed since 1600,
ie it is an absolute time.
If the 64bit integer is negative it instead represents a time-delta, i.e.
relative time. If the 64 bit integer is negative,
the 2-complement of the value represents the time delta in 100ns quantas.
Thus, 0x7fffffffffffffff would be the largets absolute time possible to
represent and this would be sometime really really far into
the future, i.e. eternity.
Thus 0x8000000000000000 would be the largets possilble relative time
specified, ie a time delta of really really long time.
I would guess that 0x8000000000000000 would be semi-common for stuff where
something is defined never to expire.
Though we should perhaps move packet-smb.c/dissect_smb_64bit_time() into
packet-dcerpc.c/dissect_ndr_time() instead
(since DCERPC uses the same representation for time)
but then we would need to change the interface to tyhe function to match
what is common in packet-dcerpc
also we would need to fix it so it could handle both big and little endian
representations.
And finally create a static dummy drep structure in packet-smb.c for when
packet-smb.c wants to call this function to print
a SMB NT time structure.
Any takers?
----- Original Message -----
From: "Guy Harris" <gharris@xxxxxxxxx>
To: "Ronnie Sahlberg" <sahlberg@xxxxxxxxxxxxxxxx>
Cc: "Todd Sabin" <tsabin@xxxxxxxxxxxxx>; <ethereal-dev@xxxxxxxxxxxx>
Sent: Monday, February 11, 2002 7:44 PM
Subject: Re: [Ethereal-dev] dcerpc and samr patches
> On Mon, Feb 11, 2002 at 03:09:10PM +1100, Ronnie Sahlberg wrote:
> > Attached patch fixes a few bugs.
>
> Checked in.
>
> > Thanks a million for the captures, I will use them to look through all
> > packets in them to see what other bugs can be found in samr.
>
> Frame 176 of epm-samr-udp.sniff.gz has some time values with the value
> 0x7fffffffffffffff; I assume that's some form of "not known" or "never",
> so perhaps "dissect_smb_64bit_time()" should check for
> 0x7fffffffffffffff as well as for 0 when it checks for "No time
> specified".
>
> (Perhaps it should also take, as an argument, a string to specify what
> description to give for those time values, along the lines of what
> "add_abstime_common()" in "packet-smb-pipe.c" does.)
>
> > Todd,
> > the ep* capture shows SAMR running atop UDP, but in the SAMR packets,
there
> > are some 20 extra bytes remaining after the SAMR
> > PDU, are these ethernet trailers or is it used to authenticate the
DCERPC
> > pdu?
> > They are not dissected anyway.
>
> At least in, say, frame 152 of "epm-samr-udp.sniff.gz", they're not an
> Ethernet trailer. The frame's too big to need a trailer, and it
> consists of:
>
> a 14-byte Ethernet header;
>
> a 152-byte IP datagram, according to the IP header;
>
> for a total of 166 bytes, which is the length of the frame.
>
> The DCE RPC header has a fragment length of 0x0018, i.e. 24 (why is the
> fragment length displayed in hex? It's a byte count, so I'd expect it
> to be displayed in decimal...); the DCE RPC payload, i.e. the SAMR
> packet, is dissected by the SAMR dissector as 24 bytes, ending at the
> access mask field.
>
> So I suspect it's either padding (but I don't see why DCE RPC would
> bother with padding) or something put in there by DCE RPC, such as
> authentication information.
>
> In fact, the DCE RPC 1.1 spec says "Connectionless PDUs consist of a
> header, body data and an optional authentication verifier," and says
> that the field dissected as "Fragment len" is the length of the body
> data, so that stuff is probably the authentication verifier.
>
> (Should DCE RPC use the fragment length to set the length of the tvbuff
> it hands to the subdissector?)
