Home page logo
/

wireshark logo Wireshark mailing list archives

Re: eth.fcs==0x00000000
From: Stuart Kendrick <skendric () fhcrc org>
Date: Sun, 25 Nov 2012 04:53:09 -0800

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


  By Date           By Thread  

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