On Wed, Nov 26, 2003 at 03:00:46PM -0000, Lee Davies wrote:
> Ethereal displays ethernet packets excluding the CRC sent down the wire, and
> displays the Packet Length excluding the CRC.
>
> Packet 7 in the attached file is displayed as having an "Ethernet II Frame
> check sequence error 0x2b5d86f7 (incorrect, should be 0x30b6f865)"
>
> Looking at the raw data in the bottom window, It appears as if Ethereal has
> compared the calculated CRC with the last 4 data bytes in the packet
> rather than with the actual CRC sent down the wire.
On some platforms, incoming packets captured using libpcap (the library
Ethereal, tcpdump, and a bunch of other programs used to capture
packets) on Ethernet include a CRC. On other platforms, they don't.
In either case, there is no indication supplied as to whether the CRC is
supplied. Therefore, for libpcap capture files, Ethereal tries to guess
whether a CRC is present or not, based on how much apparent padding is
at the end of the packet (the amount of padding is determined by the
claimed length of the payload above Ethernet, based on the length field
in an 802.3 header or based on whatever a higher-layer dissector, such
as the IPv4, IPv6, ARP, etc. dissector, says the length was).
If a packet is bogusly padded, as appears to be the case with packet 7 -
it was claimed to be 64 bytes long, but the packet didn't need to be 64
bytes long to hold the ARP request init, it could have been padded to 60
bytes, that being the minimum Ethernet packet length without taking the
4-byte CRC into account - Ethereal will treat some of the padding as a
CRC.
At some point we will probably add a configuration option to the
Ethernet dissector to specify, for capture file formats where it's not
known whether the captured data includes a CRC or not, whether it should
try to guess whether there's a CRC;
assume there's always a CRC;
assume there's never a CRC.
At some point in the future it might be the case that a
"next-generation" libpcap format will include an indication of how many
bytes of FCS are in the packet data ("how many" because, for PPP, it
could be 0, 2, or 4 bytes). At some point some packet capture
mechanisms might supply that information to libpcap so that it can put
an indication other than "I don't know". It is not known when that will
be the case.
