Re: eth.fcs==0x00000000

[Stuart Kendrick <skendric () fhcrc org>]

Hi Guy,

See https://vishnu.fhcrc.org/bad-fcs/

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).

So, I'm suggesting that Wireshark is behaving accurately here ...
mostly, I'm interested in the experience of other analysts:  is this a
known issue?

--sk

On 11/24/2012 10:29 PM, Guy Harris wrote:
> On Nov 24, 2012, at 1:27 PM, Stuart Kendrick <skendric () fhcrc org> wrote:
>
> > I'm seeing ARP Requests and Responses with the Ethernet Frame check
> > sequence set to all zeros
> Or, at least, ARP requests and responses with 4 octets of zero that Wireshark has decided are the Ethernet frame 
> check sequence.
>
> It's possible that Wireshark is guessing incorrectly; no capture mechanism I know of atop which libpcap/WinPcap runs, 
> if it delivers an FCS as part of an Ethernet, provides any indication whether a particular packet has an FCS or not 
> (outgoing packets probably won't have one, as they're normally generated by the network adapter), and there's no way 
> to deliver such an indication in the pcap API, so Wireshark has to guess whether there is an FCS or not, based on 
> whether there appear to be 4 extra bytes (over and above any necessary trailer) at the end of the frame.  It bases 
> that on whatever length information the protocol(s) running atop Ethernet provide, such as the IPv4 length field; the 
> ARP dissector doesn't do that (there's no explicit length field, but it could infer the packet length in at least 
> some cases), so the heuristics might give the wrong answer.  Does Wireshark report that any IPv4 or IPv6 packets have 
> an FCS?  If not, maybe it's incorrectly concluding that the 
>  ARP pack
>  ets have an FCS when it's just part of a trailer.
>
> Alternatively...
>
> > .... the expert layer flags these as 'Ethernet
> > Frame Check Sequence Incorrect'
> >
> > Tentatively, all the emitters of these ARPs are Windows guests on a
> > VMWare cluster ...
> ...if this is going over a virtual interface, the FCS only protects against virtualization software bugs and memory 
> bus problems, so the virtual interface may well not bother to fill in the FCS, and may just leave it as zero, so the 
> heuristics might be giving the right answer, but the packet may not have a real FCS.
>
> Could you send one of the frames that Wireshark claims has an all-zero FCS?
>
> ___________________________________________________________________________
> 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


___________________________________________________________________________
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