Hi y'all, I am using a ProfiShark 1G tap from ProfiTap in direct capture mode to look at all traffic going to/from my computer (this basically pushes all in-line traffic through a USB3.0 cable directly to my hard drive and stores it as a .pcapng-file). At the same time I am also capturing the traffic off my local NIC using Wireshark. Thus, I am basically capturing the same traffic twice (wire and NIC), just to compare. When I compare the 2 trace files it is apparent the trace file from the tap contains packets that are consistantly 4 bytes longer. It looks like the 4 extra bytes are the Ethernet_II frame check sequence (FCS). For most dissectors in Wireshark these extra 4 bytes appear to be unproblematic, but SOME dissectors report the packets as [Packet size limited during capture]. This is at least true for ARP, STP, CDP, IGMPv2 and MDNS. I have tried to change the protocol setting: "EthernetII -> Assume packets have FCS" but this appears to have no influence on how these protocols are interpreted by Wireshark. All packets of these types look good in the trace trace taken off my local NIC - the only apparent difference is they are all 4 bytes shorter. Could this be a per dissector problem or is there some global setting I am missing? I am running Wireshark version 2.2.2 (v2.2.2-0-g775fb08) on Windows 8.1 asked 22 Nov '16, 04:13  www_wireshar... |
2 Answers:
Here are 3 traces showing ARP traffic to/from my computer during pinging. The trace files have been anonymized using TraceWrangler. They are NOT captured at the same time, but show the same behaviour described in my original post. 1: Trace file captured from my local NIC using Wireshark v2.2.2 Requests are 42 bytes in length and replies are 60 bytes long. In every frame the "Frame length" and "Capture length" are the same. http://home.bi.no/edb00004/wireshark_traces/ARP_local_nic_anon.pcapng Wireshark reports no errors dissecting the frames. 2: A "direct capture" trace file from the tap with "Keep CRC32" unchecked on the tap. All ARP request and response frames are 64 bytes long. The "Frame length" is however always 4 bytes longer than the "Capture Length". Looks like the tap sees all frames including their 4 byte CRC on the wire, but leaves out the CRC part in the captured frame. http://home.bi.no/edb00004/wireshark_traces/ARP_ProfiShark_tap_do_not_KeepCRC32_anon.pcapng Wireshark reports [Packet size limited during capture] errors dissecting the frames. 3: A "direct capture" trace file from the tap with "Keep CRC32" checked on the tap. All ARP request and response frames are 64 bytes long, and the "Frame length" and "Capture length" are both 64 bytes. The tap passes on the entire frame, including the CRC. http://home.bi.no/edb00004/wireshark_traces/ARP_ProfiShark_tap_KeepCRC32_anon.pcapng Wireshark reports no errors dissecting the frames. I kind of answered my own question here :-) What happened was that Wireshark threw the [Packet size limited during capture] due to the fact that the frame length reported by the tap included the CRC/FCS, while the captured frame did not (in the traces in the original post I did not have the "Keep CRC" set at the tap). Hence the 4 bytes shorter frames and Wireshark correctly marking them as being smaller than the original one seen by the tap. Regarding the differently sized ARP requests in the different trace files - 42 bytes in the local trace vs 64 bytes when the tap sees them. All Ethernet_II frames need to be padded up to the minimum of 64 bytes to comply with the standard (802.3). This padding and the CRC are stripped by the local NIC before being picked up by Wireshark, that is why we only see 42 byte sized ARP requests in the client trace (trace #1). Edit: As Bob Jones states below in his answer to this post - the smaller frames (<60 bytes) all originate at the host where the trace is taken. Phew - I am experiencing a steep learning curve here! answered 23 Nov '16, 00:26 www_wireshar... edited 23 Nov '16, 03:25 Nothing to add, so please accept your own Answer by clicking the checkmark (not thumbs up) next to it. The point is that only the user asking the Question may accept Answers, all others can only vote them up and down, and accepted Answers are highlighted in green in the list to indicate usefully answered Questions. (23 Nov '16, 01:18) sindy 1 I would like to add some comments for the following:
The small frames, i.e. less than the Ethernet minimum, would be frames sent from the host that is running the capture utility. I would also characterize it as the frames get sent to the capture process, i.e. libpcap or what have you, prior to being sent to the driver/NIC, which will do the padding to the minimum size (60bytes) and then add the 4byte FCS. This is also true in general for offload engines: sometimes, frames larger than the Ethernet maximum are observed from the sending host as they are sent to the capture process before being fully processed, i.e. segmented, padded, etc., into standard Ethernet frames. However, for frames coming into an interface from the network, they are typically the correct size. I use this difference to identify if the capture tool is run on a host, and which host - the small frames are one way to tell by looking at the src MAC. Any received frames are usually within the Ethernet standards. (23 Nov '16, 02:24) Bob Jones |
Have you tried setting the Ethernet Dissector preference "Assume packets have FCS"? answered 22 Nov '16, 11:15  grahamb ♦ I think he said he did. So, an sample of that capture would be welcome. (22 Nov '16, 14:58) Jaap ♦ |
Publishing an illustrative excerpt from the capture (you may find @Jasper's capture file publishing tutorial helpful) would allow a better insight. Capture files with Ethernet II FCS are rare, proportionally to dedicated capture interfaces.
For my own interest I would like to look at the traces. However, it seems that they are not available any more. Would it be possible to have them available for a little while (or maybe permanently for future visitors of this question?)
They are still on the web server, but you will need to right click the link and choose "Save Target As" - at least in my browser the .pcapng format is not automatically recognized and passed on to Wireshark. If that doesn't work, just paste the link (less the filename) and that should give you a file list view in your browser of choice.
Edit: for some reason that didn't work at all.... I have now placed them all in a .zip file: http://home.bi.no/edb00004/wireshark_traces/ARP_local_nic_anon.zip
I will leave the traces on our web server, but you are free to move them to another location if that is more practical :-)
Nope,
save as...just saves the html 404 document under the name of the original file. The zip onhome.bi.nocan be downloaded normally.As for the contents, I'm afraid TraceWrangler doesn't expect that the packets would contain an FCS, which is why Wireshark doesn't report frames to be cut short but reports FCS error. Am I right, @Jasper?
Thx for creating the .zip file! :-)