Home page logo
/

wireshark logo Wireshark mailing list archives

Re: eth.fcs==0x00000000
From: Guy Harris <guy () alum mit edu>
Date: Sun, 25 Nov 2012 11:14:51 -0800


On Nov 25, 2012, at 4:53 AM, Stuart Kendrick <skendric () fhcrc org> wrote:

Originally, I saw this behavior using Wireshark running on a Windows
guest inside the VMWare cluster.

However, I took the trace posted above using a Fluke Optiview XG (one of
its 'Network Ports', i.e. a port backed by custom hardware, capable of
line-rate capture), plugged into a switch port belonging to the relevant
VLAN, capture filter set to capture only ARPs.

As confirmation, I also ran Wireshark on a Windows VM inside the VMWare
cluster and saw similar behavior (i.e. intermittent frames flagged with
ETHERNET FRAME CHECK SEQUENCE INCORRECT).

...and with Wireshark claiming that 0x00000000 at the end of the frame is the bad FCS in question?

So, I'm suggesting that Wireshark is behaving accurately here ...

I'm not so sure.

The packets are longer than ARP frames need to be - those frames *could* have fit in a minimum-sized Ethernet frame (60 
bytes, not including the FCS), but there's a whole bunch of zeroes past byte 60 and past byte 64, which means the 
Wireshark FCS-detection heuristics concluded that there's an FCS at the end.

So, other than the sending machine maybe wasting some bandwidth by sending frames bigger than they need to be (from 
your statement about how it was captured, I'm assuming this isn't a completely-virtual interface that just sends 
traffic between virtual machines running on the same host), there may be no real issue here.

If you saw this *only* with a capture done with Wireshark, I'd be pretty much certain about that.  However, *if* the 
OptiView XG doesn't have a regular Windows 7 driver running the adapter on the network port you're using, but is using 
its own custom driver, and if the hardware behind that port allows it to deliver the FCS to the CPU in the tablet, it 
could be capturing the FCS.  Does Wireshark see an FCS in any frames *other* than the frames that are padded out with 
zeroes to a size larger than needed?  If not, this is probably just a question of the guest in question (or the host?) 
putting out extra padding for some reason, breaking Wireshark's heuristics.  (Fluke have their own network analysis 
tools; are they reporting any problem with frames with bad FCSes?  Are any of the ARP requests Wireshark thinks have a 
bad FCS getting responses?)
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault