On Nov 24, 2012, at 1:27 PM, Stuart Kendrick <skendric@xxxxxxxxx> 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 packets 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?