Willy wrote:
<While monitoring LAN traffic today I noticed one of the controllers was spitting out DCERPC protocol packets as seen by Ethereal (Win
<ver). This only occurs when the fifth data byte is 5 (with 4 0's leading it). When the packet data is any of the other numbers we use (1-7) it is
<represented properly as an 80 byte data packet. All data in the packets is the same with the exception of the fifth byte which we use as a
<controller ID number.
< The question is what triggers a packet to be DCERPC? I can't seem to find a simple reference to this. We aren't (at the current time)
<experiencing any data problems (we know of) at the receive end. But there is some concern that our byte allocation in the data packet may
<be causing this. Is there a reference to this protocol somewhere that won't require wading through code to find the answer?
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.
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.
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.
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.