https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14592

--- Comment #3 from Christopher Maynard <christopher.mayn...@igt.com> ---
(In reply to LorenAmelang from comment #2)
> Thanks for the reply! I just spaced through several of the packets from this
> device, trying to learn how this issue arises. It looks like Wireshark
> recognizes some of the zero bytes at the end of short packets as padding,
> but leaves the last four to be a checksum _if_ the total length is 64 bytes. 

The minimum Ethernet frame size is 64 bytes, but that *includes* the 4 bytes of
the Frame Check Sequence (FCS) number, as well as the other 14 bytes of the
Ethernet framing (MAC destination + MAC source + Ethertype) for a total of 18
bytes of Ethernet framing overhead.  (See
https://en.wikipedia.org/wiki/Ethernet_frame#Structure for more information). 
Thus, 64 bytes minimum - 18 bytes Ethernet framing overhead leaves a required
minimum of 46 bytes of payload.  If the payload length is less than 46, padding
of the payload is needed in order to bring the payload up to at least 46 bytes.
 Unfortunately, some devices incorrectly *overpad* by 4 bytes, which then
causes Wireshark to interpret those extra 4 bytes as the FCS.

> But longer packets don't seem to have that checksum at all, at least here. I
> read several places that in some environments (like Windows?) those
> checksums are stripped off by the network interface before Wireshark sees
> them. 

Longer packets don't require any padding.  But whether there's padding or not,
your NIC is almost certainly not delivering the Ethernet FCS to your capture
tool.  Unless you have special hardware (like a TAP) or have a NIC that allows
the FCS to be captured, you're never going to see the real FCS bytes.

> I saw the "Validate the Ethernet checksum if possible" option, but I thought
> disabling it would likely hide some real problem someday! So I didn't. But
> it looks like Wireshark on this machine will never see an actual valid or
> invalid Ethernet checksum, only these misplaced zeros, so there is nothing
> to lose...  

If you don't have the FCS, you can safely turn that option off, as there's
nothing to be gained by enabling it in your case, and only confusion to be
caused when you have a faulty device overpadding like it appears that this one
is.

> But then what does "Assume Packets have FCS" change? I guess it chooses
> between always trying to make other bytes a checksum, and using the
> algorithm that gets confused by padding to 64 bytes? Rather than using the
> algorithm vs. assuming there is never a checksum?

If "Assume Packets have FCS" is enabled, then Wireshark does just that and
assumes the last 4 bytes of *every* Ethernet frame is the FCS, but this will
not be the case for you.  Try turning it on; you will get tons of malformed
packets as a result.  That's because all the IP length fields will now be
assumed to be 4 bytes too big.  You don't want to enable that option.

> Could it be smart enough to notice if long packets from a particular
> interface have their checksums stripped, and report an "improper padding"
> error for short packets, rather than assuming they have real checksums that
> are incorrect? Especially if those checksums are all zeros? 

I can't think of any reliable way for Wireshark to know whether a device
incorrectly adds extra padding vs. the FCS is present and invalid.  Since
you're in control of your capture device, and you know FCS's aren't present,
the easiest and most reliable way to stop seeing those false positives is
simply to disable Ethernet FCS validation.

> Otherwise I guess you're stuck helping us users learn these details...  I
> appreciate your help!

Well, nobody is stuck doing anything here.

-- 
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via:    Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
             mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

Reply via email to