Wireshark-users: Re: [Wireshark-users] Mismatch between frame.protocols, _ws.col.Protocol, filter
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Pascal Quantin <pascal.quantin@xxxxxxxxx>
Date: Mon, 4 Jun 2018 15:14:33 +0200
Hi Marcin,


Le lun. 4 juin 2018 à 14:56, Marcin Nawrocki <marcin.nawrocki@xxxxxxxxxxxx> a écrit :

Hi list,


I stumbled upon a mismatch across fields indicating the protocol. Consider this extract of traces from the public MAWI WIDE archive (no payload): https://www.cloudshark.org/captures/c9752d3184ee



Case 1 [BVLC] Case 2 [HART_IP] Case 3 [enip]



frame.protocols contains "bvlc" is true frame.protocols contains "hart_ip" is true frame.protocols contains "enip" is true
_ws.col.Protocol shows UDP _ws.col.Protocol shows hart_ip _ws.col.Protocol shows ENIP
using display filter "bvlc" yields no results using display filter "hart_ip" yields no result using display filter "enip" yields results


Why do we see different behavior for case 1-3, how does it relate to the quality of the dissectors?

case 1: you have packets using the UDP port defined for BVLC, but only the UDP header is captured and not the UDP payload. As the BVLC dissector first checks the first byte of the packet to know whether it is really BVLC or not, and as the first byte is missing from the capture (only 42 bytes were captured out of 60), the [Packet size limited during capture: BVLC truncated] line is displayed and dissection stops before the protocol column is added or any field can be filtered.

case 2: The HART_IP dissector updates the info column before trying to access the payload content to add the first item. Dissection stops with the [Packet size limited during capture: HART_IP truncated] because no payload is captured.

case 3: The ENIP dissector code updates the protocols column and adds the protocol name to the tree before trying to access to the payload data (and trigger the [Packet size limited during capture: ENIP I/O truncated] exception).

To summarize: what you see is different behavior depending on how the dissector was written in the specific case were no UDP payload was captured at all. Capturing it would have led to different (and coherent) results for the 3 protocols.

Best regards,
Pascal.