I have a Chromebook that is running chrubuntu. I've tried capturing my traffic (on my host) with Wireshark and tcpdump with the same result - I'm getting a lot of frames that are over 1700 bytes in size. This is highly unusual as the network doesn't support jumbo frames and the MTU on the NIC is set to 1500. Wireshark also complains that these packets have a ethernet frame check sequence error. I've tried updating libpcap to the latest version and built Wireshark from the latest source. Based on the ARM version of Ubuntu not receiving a lot of attention, I'm speculating this could be a NIC driver issue (it's version 1.0). Any ideas on how to resolve this? asked 31 May '13, 07:31  randrews_01 |
3 Answers:
TCP Offload? The NIC hardware may be segmenting the data into proper size segments and calculating the FCS so at the point of capture this hasn't yet been done, hence the effects you see. Try capturing communications to another device connected to your Chromebook on the other device at the same time to see if this is true. See the Wiki page on offloading. Update: Are the frames that are affected (size and fcs) all outgoing from your Chromebook? If that's the case it's definitely an offloading issue of some sort. answered 31 May '13, 07:44  grahamb ♦ edited 31 May '13, 09:02 They are all inbound frames. (31 May '13, 09:12) randrews_01 Inbound frames with an FCS error? That's very odd. (31 May '13, 09:26) grahamb ♦ |
That's most certainly the effect of TCP offloading into the driver. In that case Wireshark will see large packets and the nic driver will take care about TCP segementation. You can check/disable TCP offloading on Linux with ethtool.
See also here:
Regards answered 31 May '13, 07:46  Kurt Knochner ♦ edited 31 May '13, 07:50 Hi, Thanks for the tips. I checked with ethtool and TSO was already set to off. The only thing set to on was generic-receive-offload. (31 May '13, 08:57) randrews_01 well, then turn that off ;-)) (04 Jun '13, 13:02) Kurt Knochner ♦ Turned it off - no difference. I think I'm going to file an OS bug. (04 Jun '13, 15:37) randrews_01
Wait a moment? Did you capture the traffic on the Chromebook or did you capture the traffic off the Chromebook on another system? (04 Jun '13, 22:34) Kurt Knochner ♦ Is this traffic possibly internal loopback traffic not leaving the chromebook? (04 Jun '13, 23:01) mrEEde2 |
"frame.len gt 1506 and !eth.trailer gt 0" vs. "frame.len gt 1506 and eth.trailer gt 0" shows that the enlarged packets are due to an added ethernet trailer on inbound packets coming from MAC address "Sonicwal_59:9f:6d". The frame.len is exceeding the standard 1506 (1492 MTU+14 MAC) by an eth.trailer (+ padding) that is obviously added on all inbound frames by a sonicwall VPN client that seems to be running on the chromebook. So, even though this sets off wireshark's expert logic, it should not do any harm to your real data traffic. I suggest you contact sonicwall to get this 'fixed'. answered 05 Jun '13, 11:59  mrEEde2 There isn't a VPN client on the Chromebook. In fact Sonicwall doesn't even support ARM and Chrubuntu so it would be impossible to install :) Like I mentioned earlier - if I capture upstream of the host I get normal sized frames. I also get normal sized frames from hosts on the other segments. (05 Jun '13, 12:07) randrews_01 Sorry for the confusion then. Wonder how this MAC address prefix comes from then... What exactly do you mean by "if I capture upstream of the host". Is that tracing externally in the ethernet? And then also your inbound frames going to 192.183.3.11 look 'normal'? (05 Jun '13, 12:16) mrEEde2 Ok, there is one other ARP packet arriving that also has an ethernet padding/trailer added to the MAC header which comes from an Intel machine: eth.src == c0:ea:e4:59:9f:6d. This one also has a wrong FCS. So the SonicWall is not the only one and therefore is not causing this. (05 Jun '13, 13:09) mrEEde2 Ok, we're getting closer. The problem seems to be that the packet capture software fills every inbound frame with some residual data when writing it to the pcap file. Wireshark interprets those as ethernet padding/trailer/FCS. How exactly did you capture the trace data? (06 Jun '13, 07:57) mrEEde2 Boot laptop. Start Wireshark on laptop. Capture on mlan0. Surf websites on same laptop. Stop capture. (06 Jun '13, 08:46) randrews_01 .. and using tcpdump you are getting the same results? (06 Jun '13, 09:00) mrEEde2 tcpdump = same results (06 Jun '13, 09:11) randrews_01 ok, so the problem seems to be in writing additonal bytes to the capture file which were never received by the mlan0 adapter. This is generating false alerts in wireshark but should not have any adverse effect in your traffic. The easiest way is to disable the FCS validation in the ethernet preferences. In addition (ch)ubuntu experts should be looking at this to ... (07 Jun '13, 13:51) mrEEde2 showing 5 of 8 show 3 more comments |
Pcap is shared here: http://snk.to/f-ctn86ppz Again, this is a capture running from the host itself i.e. Wireshark on Chrubuntu