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: Guy Harris <gharris@xxxxxxxxx>
Date: Mon, 11 Feb 2002 00:44:27 -0800
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?)