In order to fix this and other possible issues, maybe we have to define a
*real* private_data *structure* containing the information about the
protocol (such as the protocol dissector handle?) to which it belongs and a
"pointer-to-void" as is the case today.
Maybe we should also add a call-back routine to it so we know when the
private data can be freed?
Regards,
Olivier
|-----Original Message-----
|From: Todd Sabin
|
|Ok, you're going to love this (or not). First, applying this patch
|should solve the problem, although it is not really the right fix.
|
|Index: packet-dcerpc.h
|===================================================================
|RCS file: /cvsroot/ethereal/packet-dcerpc.h,v
|retrieving revision 1.42
|diff -u -r1.42 packet-dcerpc.h
|--- packet-dcerpc.h 9 May 2004 10:03:37 -0000 1.42
|+++ packet-dcerpc.h 8 Jun 2004 14:10:38 -0000
|@@ -228,7 +228,7 @@
| pass transport specific information down to the dissector from the
| dissector that parsed this encapsulated calls. */
|
|-#define DCERPC_TRANSPORT_SMB 1
|+#define DCERPC_TRANSPORT_SMB 0x12345678
|
| typedef struct _dcerpc_private_info {
| int transport_type; /* Tag */
|
|
|Now, why on earth should that help, right?
|
|The reason that your packets weren't identified as EPM packets
|is that when dcerpc_binds hashtable is consulted to find the uuid that
|goes with the context id in the rqst/rply, it can't be found. But,
|the bind packet is there in sniff, so why can't it be found?
|
|The binds hash table is keyed on the conversation, context id, and
|(wait for it) smb_fid. But the sniff doesn't contain any SMB traffic,
|so why should that matter?
|
|The dcerpc dissector always tries to include an smb_fid by calling
|get_smb_fid (), which looks at private_data. And here's where things
|go south. get_smb_fid () just assumes that private_data is a pointer
|to dcerpc_private_info (if it's not NULL). But there's no guarantee
|of that, and it won't be true unless dcerpc has been called from the
|smb dissector.
|
|In this case, dcerpc is being called directly by the tcp dissector,
|and so private_data is actually pointing to a struct tcpinfo. Now,
|get_smb_fid() just treats that as a dcerpc_private_info, and so the
|seq from struct tcpinfo becomes the transport_type of
|dcerpc_private_info. (Assuming int and guint32 are the same size.)
|If the seq from struct tcpinfo happens to be 1, get_smb_fid() will
|think there's a meaningful smb_fid in the private data, and use it.
|
|This is what happens in your first sniff, which is dissected wrong.
|Because of the presence of the syn/ack packet, the (relative) seq in
|the bind packet is 1, and the dcerpc_binds key contains a totally
|bogus smb_fid. Your second sniff doesn't contain the syn/ack, so the
|relative seq is not 1, and it's keyed properly.
|
|It's important to note that the first sniff is the way things normally
|occur in the ncacn_ip_tcp scenario, so _all_ dcerpc over tcp sessions
|are going to have this problem, and it's not just a property of having
|anonymized a sniff. I've confirmed that my normal dcerpc over tcp
|sniffs are dissected wrong by CVS head, too.
|
|As for why this doesn't apparently happen on Mac OS X, I'm not sure,
|but suspect it has something to do with endianness being different.
|E.g. if int and guint32 are different sizes in the Apple build, that
|would explain it. I wouldn't expect that they are, but I think it's
|probably something like that.
|
|Now, someone's probably thinking, "How did this ever work?" It seems
|that this misuse of struct tcpinfo as dcerpc_private_info has been
|going on for a long, long time, but what used to save us is that the
|members of struct tcpinfo that were being misused as smb_fid happened
|to be 0 almost all the time.
|
|According to
|http://www.ethereal.com/cgi-bin/viewcvs.cgi/ethereal/packet-tcp.h, Guy
|checked in a change on Dec 30 last year that added nxtseq in the
|middle of struct tcpinfo. Prior to that, the stuff immediately
|following the seq was is_reassembled, urgent, and urgent_pointer,
|which are typically zero. nxtseq is typically _not_ zero, so we have
|this problem.
|
|That change has been in starting with 0.10.1. I tried building that
|from source, but couldn't, due to missing files. 0.10.2 did build,
|and does in fact have this problem. 0.10.0a does not have this
|problem. So, I'm pretty sure this is the answer.
|
|Anyway, the patch above is just a harmless band-aid to make things
|work again. (Although, if the tcp seq happens to be 0x12345678 in a
|dcerpc bind packet, it'll still be handled wrong.) The right fix is
|to stop the misuse of private_data. This kind of confusion can result
|any time a dissector might be called by two different dissectors, each
|of which is trying to pass different private_data. I have no idea
|what the right way to fix that is, but perhaps the different types of
|private data should be registered, and the type of private data
|included along with the private data.
