Ethereal-dev: Re: [Ethereal-dev] dcerpc and samr patches

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Todd Sabin <tsabin@xxxxxxxxxxxxx>
Date: 11 Feb 2002 10:28:21 -0500
Guy Harris <gharris@xxxxxxxxx> writes:
> On Mon, Feb 11, 2002 at 03:09:10PM +1100, Ronnie Sahlberg wrote:
> > 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.

Yes, that's the auth info.  I haven't added dissection of it to the
connectionless side of dcerpc yet.  Part of the problem is that it's
not exactly well documented what the stuff means.  The OpenGroup specs
describe (more or less) what things look like when you use their
kerberos based auth scheme, but for NTLMSSP, it's not clear.
Apparently, the format can also vary by protect level.  I have a fair
idea how things work with NTLMSSP and protect level 4, but am not
familiar with others.  At minimum it could just be dissected as a
DCERPC AUTH blob, I guess.

> 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

That's just my hex bias.  I prefer hex most of the time; feel free to
change it to decimal if that fits better with the way ethereal
normally does things.  Actually, it'd be nice to be able to select
that at run time, but I'm guessing that's non-trivial.

> packet, is dissected by the SAMR dissector as 24 bytes, ending at the
> access mask field.
> [...]
> (Should DCE RPC use the fragment length to set the length of the tvbuff
> it hands to the subdissector?)

Yes.  The connection oriented side does that already.  The
connectionless should as well.  I'll try to send a patch in a day or
so, if someone doesn't fix it first.

BTW, the Auth stuff follows the stub data, so it'd probably be more
obvious if it came after it in the proto tree.  For the connection
oriented stuff, I just added it to the end of the DCERPC tree.  Be
nicer as

+ DCERPC
+ SAMR (or whatever)
+ DCERPCAUTH

That's what NetMon does, though it calls it "SSP" for Security Support
Provider.


Todd