Re: Mismatch between frame.protocols, _ws.col.Protocol, filter tag

[Pascal Quantin <pascal.quantin () gmail com>]

Hi Marcin,


Le lun. 4 juin 2018 à 14:56, Marcin Nawrocki <marcin.nawrocki () fu-berlin de>
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
> <https://www.cloudshark.org/captures/c9752d3184ee?filter=frame.protocols%20contains%20%22bvlc%22> frame.protocols
> contains "hart_ip" is true
> <https://www.cloudshark.org/captures/c9752d3184ee?filter=frame.protocols%20contains%20%22hart_ip%22> frame.protocols
> contains "enip" is true
> <https://www.cloudshark.org/captures/c9752d3184ee?filter=frame.protocols%20contains%20%22enip%22>
> _ws.col.Protocol shows UDP _ws.col.Protocol shows hart_ip _ws.col.Protocol
> shows ENIP
> using display filter "bvlc" yields no results
> <https://www.cloudshark.org/captures/c9752d3184ee?filter=bvlc> using
> display filter "hart_ip" yields no result
> <https://www.cloudshark.org/captures/c9752d3184ee?filter=hart_ip> using
> display filter "enip" yields results
> <https://www.cloudshark.org/captures/c9752d3184ee?filter=enip>
>
> 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.

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe