Wireshark · Ethereal-dev: [Ethereal-dev] Re: dce rpc type packets

[Jeff Davis <jdavis-ethereal@xxxxxxxxxxx>]

Ok, I made it definately further. Thanks very much for your reply, it gave me 
a lot to work with. I found out that the conversation wasn't being recognized 
because I was sending packet #3 to the initial connection port rather than 
the port from which the request (packet #2) came. I forgot to initialize the 
fromlen argument to recvfrom, so it wasn't changing the port (dumb mistake, I 
know). As soon as I got the to/from ports right, the #3 packet was properly 
being recognized as part of the CONV. The source code reference you gave me 
really helped me find that problem, after I read a little into 
find_conversation().

Anyway, I'm still not getting any acknowledgement for my packet #3. The server 
just keeps asking me with a who_are_you request (just like packet #2), but 
the serial_low field increments with each subsequent request. Other than that 
the packets are identical to packet #2. The packets I recieve, as well as all 
packets in the valid conversation I was viewing (between the two windows 
computers) all have sequence number 0.

(some of your questions are answered in the text)

> On Sat, Jan 25, 2003 at 09:11:54PM -0800, Jeff Davis wrote:
> > I've been trying to communicate with a server over DCE RPC.
> >
> > I ask this question to this list because the source for ethereal seems to
> > be helpful, because it tells me some things about DCE RPC and
> > conversations. However, I haven't been able to make complete sense out of
> > the source, so I was hoping that someone here could help.
> >
> > Here is what I think I've found out so far:
> > (1) I send a request packet (type 0x00) with a random activity id and an
> > object ID of all zeros. Ethereal marks it as "DCERPC" protocol in the
> > main window.
> > (2) I get a reply, asking "conv_who_are_you" (which is a a request also,
> > type 0x00)
>
> From the standpoint of DCE RPC (and definitely from the standpoint of
> Ethereal's DCE RPC dissector), it's presumably only a request (PDU type
> 0), not a reply (PDU type 2), even though the packet was sent in
> response to the packet you sent in 1).
>
> > with a new activity ID, and a ht_conv_who_are_you2_rqst_actuid equal to
> > the activity ID I randomly generated. Ethereal marks it as protocol type
> > "CONV".
> > (3) I send a "conv_who_are_you2" as type response (0x02) with activity ID
> > equal to the activity ID of the packet in (2) and a "casuuid" that I
> > can't make sense of.
> >
> > The problem is that number (3) is marked as a DCERPC request (by
> > ethereal), with the "Request In:" set to the packet that *I* sent out.
>
> There is no "Request in:" item in DCE RPC requests.  Are you saying that
>
> 	1) packet 3 is marked as a DCE RPC *reply*, with "Request in:"
> 	   showing the packet you sent out (which packet is that - 1 or
> 	   3?)
>

Right, (1) is correct. It said the Request in: was the packet #1 that I sent 
out. That was before I fixed it, now that's taken care of.

>
> 1) is a *lot* more likely than 2) - it'd be pretty hard for Ethereal to
> misinterpret a DCE reply as a DCE request, as it bases that purely on
> the PDU type.
>
> I shall assume it's 1).
>
> > Furthermore, the
> > details I included at the bottom (casuuid, etc) were not recognized as
> > anything more than "stub data".
> >
> > I ran ethereal while the correct application was sending/receiving data
> > (when the communication was working), and the # (3) packet was marked as
> > another "CONV". This correct packet has all of the right DCE RPC
> > conversation manager information in it at the bottom (I'm still refering
> > to the working conversation).
> >
> > The only difference between the working conversation and my conversation
> > were the activity IDs (which always changed), at least within the UDP
> > part of the packet.
>
> To quote a comment in "dissect_dcerpc_dg()":
>
>     /*
>      * keeping track of the conversation shouldn't really be necessary
>      * for connectionless packets, because everything we need to know
>      * to dissect is in the header for each packet.  Unfortunately,
>      * Microsoft's implementation is buggy and often puts the
>      * completely wrong if_id in the header.  go figure.  So, keep
>      * track of the seqnum and use that if possible.  Note: that's not
>      * completely correct.  It should really be done based on both the
>      * activity_id and seqnum.  I haven't seen anywhere that it would
>      * make a difference, but for future reference...
>      */
>
> The dissector for datagram DCE RPC matches requests and replies based
> on conversation, sequence number, and SMB FID (which is done because a
> conversation is a transport-layer conversation, but if DCE RPC is
> running over SMB, there can be more than one DCE RPC session over the
> same transport-layer conversation).

I don't see any SMB layer to the protocol. I could be missing something, but 
it looks like all the data is in the DCE RPC, or the DCE RPC Conversation 
Manager, or the stub data. So, I couldn't find any SMB FID.

>
> The transport-layer conversation, for DCE RPC over UDP, is set up based
> on source and destination port and address (for ONC RPC over UDP, we
> ignore the server address, as I remember, in case the server is
> multi-homed and replies with a different address from the one to which
> the request was sent; we might have to do the same here - are replies
> coming from the address to which the requests were sent?).
>

Yup, that's where I made my mistake described above. The IP was right, but the 
port wasn't (due to dumb error that I missed).

> What are the sequence numbers in packets 1), 2), and 3)?  If the same
> sequence number is used in all of them, this might be a place where "it
> would make a difference" if connectionless DCE RPC matching is done
> based on the seqnum or if it's done based on the activity_id and seqnum.

In the valid communication that I was seeing between the two windows computers 
all the sequence numbers were 0, as well as all serial high and serial low. 
If the server duplicated a request to me (because, for example it doesn't 
recognize my response), it would increment the serial low, but that never 
happened in the windows-windows communication. I've tried incrementing the 
sequence number for each packet I send, but that doesn't seem to affect 
anything.

I still don't really know what interface ID is supposed to be set to, but it 
looked so consistant in the windows-windows communication that I thought I 
had it right. Now I think it's likely that's where I'm going wrong. I also 
don't understand what CASUUID is supposed to be set to, I've tried copying 
from the windows packets and also random.

Thanks again,
	Jeff Davis