Ethereal-users: Re: [Ethereal-users] Bytes/sec in summary includes Ethernet header? Trailer?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Fri, 18 Jan 2002 18:55:42 -0800 (PST)
> Most PC based NIC cards do not pass the CRC up to the PC. If the CRC is bad,
> the NIC card normally just drops the packet.

Some network chips can be configured to deliver bad frames and to
deliver the CRC, e.g. some Intel chips, such as the 82559 (and possibly
at least some other 8255x chips).

In the 82559, there's a "save bad frames" bit in one of its
configuration control blocks (so that you see (and the FreeBSD 4.3
driver appears to set that bit in the 8255x driver "if_fxp.c" if it's
putting the interface into promiscuous mode).

There's also a "transfer the CRC to host memory" bit (which the FreeBSD
4.3 driver always clears), and there are various per-frame error bits
including a "CRC error bit" (the driver doesn't deliver that flag word).

So, in theory, at least some network interfaces can provide that data;
however, if the driver doesn't enable the features necessary for that,
there's nothing Ethereal (or any other sniffing software) can do about
it.  (Neither the Ethereal development team nor the tcpdump/libpcap
development team are in the business of doing network card drivers;
commercial sniffer vendors may have the time or resources to make their
sniffer hardware support that, or to supply drivers to allow you to make
a sniffer capable of handling that out of, say, a PC plus their driver,
but we don't.)

Note also that if the sniffing is done on a machine that's also
transmitting on the network, you aren't going to see the CRC for packets
transmitted by the machine doing the sniffing, as the packets
transmitted by that machine will be handed to the packet capture
mechanism by the driver and networking code as part of the transmission
process - they won't be received by the networking card with the CRC on
it.  (Furthermore, if the network interface is doing TCP checksum
offloading, the packets received by the packet capture mechanism might
not have valid TCP checksums; that's why I just checked in a change to
disable TCP checksum checking in Ethereal's TCP dissector *and* to allow
reassembly of packets atop TCP if checksum checking is disabled.)