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

[Guy Harris <gharris@xxxxxxxxx>]

(Moving this to ethereal-dev, as this is probably an issue with the DCE
RPC dissector.  Replies have been set to ethereal-dev@xxxxxxxxxxxx; do
not override that and send replies to me, based on an incorrect
assumption that I'm taking ownership of this issue by replying.)

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?)

or that

	2) packet 3 is marked as a DCE RPC *request*, with "Response in:"
	   showing the packet you sent out?

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).

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?).

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.