>
> ...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?)
Ahhh. I had never thought through this. I'm realizing that I had this
vague mental image that the last four bytes were 'colored' differently
... perhaps orange ... indicating that they belonged to the FCS. But of
course, bits are not colored ...
So a NIC must grab the last four bytes of the frame ... it knows nothing
about padding ... calculates the FCS, and discards if the last four
bytes don't match its calculated FCS.
The analyzer has to know whether or not it to expect an FCS ...
Wireshark's heuristics must include various rules like "If the frame is
60 bytes long, don't look for an FCS". Perhaps other rules include
grabbing frame length fields (from IP perhaps) and figuring out whether
or not the frame includes an Ethernet FCS. And when an ARP, which
should appear in either a 60 byte frame (FCS stripped by NIC) or a 64
byte frame (FCS included) appears, instead measures > 64 bytes ...
Wireshark assumes the last four bytes are FCS. [And then there is that
Preference which would allow me to force Wireshark to calculate FCS on
the last four bytes of all frames.]
OK.
Returning to the Optiview, which includes custom hardware & custom
driver which capture FCS, along with an integrated analyzer
(ClearSight), I see that the vast majority of ARPs are 64 bytes long.
However, some frames are longer than 64 bytes ... 68 bytes ... 110 bytes
... ClearSight sees correct FCS on these (and in the hex I can see that
these four bytes are non-zero) ... however, when I 'Save As...' into
.pcap format ... ClearSight strips the FCS ... leaving the zeros padding
... and Wireshark, when it opens this file, then flags those frames with
the FRAME CHECK SEQUENCE error. [And if open the .pcap file with
ClearSight, ClearSight does the same in fact.]
OK, so I did this to myself.
Outstanding question: Why would a station pad an ARP with zeros?
Guy, Thank you for the education -- I appreciate deepening my understanding.
--sk