[prev in list] [next in list] [prev in thread] [next in thread]
List: wireshark-users
Subject: Re: [Wireshark-users] Mismatch between frame.protocols, _ws.col.Protocol, filter tag
From: Pascal Quantin <pascal.quantin () gmail ! com>
Date: 2018-06-04 13:14:33
Message-ID: CAGka-81i+qmgOnBwexFNCsn4feWzcuOSi-pVY_X4i5xC5_gGCw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
[Attachment #5 (text/html)]
<div dir="ltr"><div>Hi Marcin,</div><div><br></div><br><div class="gmail_quote"><div \
dir="ltr">Le lun. 4 juin 2018 Ã 14:56, Marcin Nawrocki <<a \
href="mailto:marcin.nawrocki@fu-berlin.de">marcin.nawrocki@fu-berlin.de</a>> a \
écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Hi list,</p>
<p><br>
</p>
<p>I stumbled upon a mismatch across fields indicating the protocol.
Consider this extract of traces from the public MAWI WIDE archive
(no payload): <a href="https://www.cloudshark.org/captures/c9752d3184ee" \
target="_blank">https://www.cloudshark.org/captures/c9752d3184ee</a><br> </p>
<br>
<br>
<table width="100%" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top"><b>Case 1 [BVLC]</b></td>
<td valign="top"><b>Case 2 [HART_IP]</b></td>
<td valign="top"><b>Case 3 [enip]</b></td>
</tr>
<tr>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top"><a \
href="https://www.cloudshark.org/captures/c9752d3184ee?filter=frame.protocols%20contains%20%22bvlc%22" \
target="_blank">frame.protocols contains "bvlc" is true</a></td>
<td valign="top"><a \
href="https://www.cloudshark.org/captures/c9752d3184ee?filter=frame.protocols%20contains%20%22hart_ip%22" \
target="_blank">frame.protocols contains "hart_ip" is true</a></td>
<td valign="top"><a \
href="https://www.cloudshark.org/captures/c9752d3184ee?filter=frame.protocols%20contains%20%22enip%22" \
target="_blank">frame.protocols contains "enip" is true</a></td>
</tr>
<tr>
<td valign="top">_ws.col.Protocol shows UDP</td>
<td valign="top">_ws.col.Protocol shows hart_ip</td>
<td valign="top">_ws.col.Protocol shows ENIP</td>
</tr>
<tr>
<td valign="top"><a \
href="https://www.cloudshark.org/captures/c9752d3184ee?filter=bvlc" \
target="_blank">using display filter "bvlc" yields no results</a></td>
<td valign="top"><a \
href="https://www.cloudshark.org/captures/c9752d3184ee?filter=hart_ip" \
target="_blank">using display filter "hart_ip" yields no result</a></td>
<td valign="top"><a \
href="https://www.cloudshark.org/captures/c9752d3184ee?filter=enip" \
target="_blank">using display filter "enip" yields results</a></td>
</tr>
</tbody>
</table>
<br>
<br>
Why do we see different behavior for case 1-3, how does it relate to
the quality of the dissectors?<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).<br></div><div><br></div><div>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.</div><div><br></div><div>Best \
regards,<br></div><div>Pascal.</div></div></div>
[Attachment #6 (text/plain)]
___________________________________________________________________________
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic