On Nov 25, 2012, at 4:53 AM, Stuart Kendrick <skendric@xxxxxxxxx> 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?)
