Hi,
For the NT time values I would vote for
adding code to dissect_smb_64bit_time() to recognize both
0x7fffffffffffff (infinity for absolute times)
and
0x8000000000000000 (infinity for relative times)
and print the text "infinity" or "eternity" or if you hae a better word.
Guy, can you add this if you think it makes sense?
---
Hmm, perhaps it is possible sometime in the future to dissect the
authentication trailer
(if whatever unknown data is prespecified to ethereal) like we check that
ip-checksums are correct.
----- Original Message -----
From: "Guy Harris"
To: "Ronnie Sahlberg"
Cc: "Todd Sabin"
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?)
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev