In response Martin wrote:
<Ethereal uses several different mechanism to determine what protocol it is
when trying to decode the packets. It is in some <cases difficult or
impossible to determine the protocol in a good way and it happens that
packets are decoded as a <completly different protocol in certain cases.
<
<As I understand it your problem is that packets that you are quite sure are
not DCERPC packets are decoded as <DCERPC.
This is very true.
<I have seen this before. I recently got a capture with iSCSI packets where
one of the iSCSI packets were decoded as <DCERPC due to that the fifth byte
was 5. The packet matched the heuristic checks for both the DCERPC and the
iSCSI <dissector and since the DCERPC dissector was called before the iSCSI
dissector the packet became decoded as <DCERPC instead of iSCSI.
Sounds pretty much like my problem!
The interesting/confusing thing was that my 80 byte packet turned into a 76
byte packet, as the leading 4 zero's were removed, or perhaps used for
further DCERPC decoding (they were still showing on the screen).
<When I disabled the DCERPC protocol (menu item Edit/Protocols... , mark
DCERPC protocol in the list of protocols so <that it is shown as Disabled
and then press Apply+Save+OK) the packet was decoded as iSCSI.
I just did that with the captured data and bingo now I have an 80 byte data
packet. Would have, perhaps, tried that while trapping the data, except that
the machine use for that all looked normal except the length was 76 bytes.
When I took the captured data to my other machine that's when the packets
all became DCERPC. Perhaps a bad install on the other machine.
<You can also try with disabling DCERPC protocol. With the latest version of
Ethereal (0.9.15) you only need to do this <once if you
<press Save, but with earlier versions you had to disable protocol each time
you started Ethereal.
<I don't know if it is possible to enhance the heuristic checks in the
DCERPC dissector to work better. My knowledge about <DCERPC is limited.
There was also some discussion of introducing a priority based how strong
heuristic checks a dissector <has. There might be other ways to improving
this behaviour.
The project I'm working will only be using the pcap libraries, I should be
able to handle it at that level. When the project is done perhaps I'll
persue this further in the code, as Ethereal is too good of a tool to have
this problem. Especially when it is used to blindly find out what traffic is
on the LAN.
Thanks for the help,
Willy