[Guy Harris <guy@xxxxxxxxxxxx>]

On Nov 17, 2003, at 12:26 PM, Ben Greear wrote:

> Guy Harris wrote:
> > On Nov 17, 2003, at 10:38 AM, Ben Greear wrote:
> > > I have made a patch to the e1000 driver (a similar patch should work
> > > on other drivers) to allow it to be configured to return the entire
> > > ethernet frame, ie the FCS too.  Eventually, if I can convince the 
> > > kernel
> > > folks, there will be an Ethtool ioctl to turn this on/off and query 
> > > it.
> > Which kernel?  (As in "kernel for what OS"?)
>
> Linux 2.4.23-pre9.

OK, so it's not as if it uses BPF.

It might be Really Nice to convince the kernel folk to have some 
mechanism by which code reading from a PF_PACKET socket could get 
information supplied by drivers - such as:

	an indication of how many bytes of FCS are in the packet (not just 
"present or absent", as PPP can have 0, 2, or 4 bytes of FCS);

	an indication of whether the packet had various link-layer errors (if, 
for example, you plan to have a "capture even packets with bad FCSes" 
setting for the driver).

That way, when we go to a next-generation libpcap format, we could 
supply that information, and, when using that format, not have to guess 
whether the FCS is present.

(Yes, I know, we're not doing that now.  I'm not advocating that as the 
short-term fix.)

> > > In the meantime, how hard would it be for someone to add an option to
> > > ethereal to tell it that a particular interface or session's packets
> > > include the FCS as the last 4 bytes?  Please note, I'm using a 
> > > hacked up
> > > proprietary protocol for my testing, so there is no way Ethereal can 
> > > know
> > > that the last 4 bytes are checksum....
> > I.e.
> >     1) this would be done with a libpcap-format capture (e.g., done 
> > by Ethereal);
>
> Ethereal shows the last 4 bytes (the checksum), it just shows them as
> part of the normal ethernet packet.

"Part of the normal Ethernet packet" in what sense?  Does it show them 
as part of a trailer, or as part of the data for your protocol?

> I'm not sure if the above was question or answer...

Question.

> >     2) your protocol doesn't run atop 802.3+802.2 (with a length 
> > field rather than a type field) and doesn't include a length field of 
> > its own, so Ethereal doesn't know how much of the packet is trailer 
> > and/or FCS and thus the existing Ethereal code to try to guess 
> > whether there's an FCS won't always work?
>
> With my patch, the last 4 bytes of the captured packet will always be
> the FCS.

Yes, and when you capture (at least on Mac OS 10.3) on the 10/100/1000 
interface on a G4 PowerMac, the last 4 bytes of captured packets 
(except for outgoing packets, but that'll presumably be the case for 
your changed driver as well) are always the FCS.

However, for protocols that either

	1) run atop 802.3+802.2, so that there's a length field rather than a 
type field in the packet

or

	2) have a length field of their own (such as IP)

the Ethernet dissector knows how much of the data in the packet after 
the Ethernet header is payload for the protocol running atop Ethernet.  
The rest is assumed to either be padding (trailer) or FCS.

Any Ethernet packet from a capture where the packet is said to have an 
FCS based on either

	1) all captures in that capture file format having an FCS

or

	2) a flag being set in the packet header saying "this packet has an 
FCS" (or that appears, from experimenting with captures, to say that)

is assumed to have an FCS.

Any Ethernet packet from a capture where the packet is said *not* to 
have an FCS based on either

	1) no captures in that capture file format having an FCS

or

	2) the aforementioned flag not being set (in capture files whose 
format includes such a flag)

is assumed *not* to have an FCS.

Any Ethernet packet, from a capture where it's not known whether the 
packet has an FCS (this includes libpcap captures), with 64 or more 
bytes of data in it, and with 4 or more bytes of padding-or-FCS, is 
assumed by Ethereal to have an FCS, as 64 is the minimum Ethernet 
packet size including an FCS and 60 is the minimum size without the 
FCS, so if it has 4 or more bytes of padding-or-FCS *and* it's 64 or 
more bytes long, that's more padding than Ethernet requires, so it's 
assumed that 4 bytes of the padding-or-FCS are FCS.

> So, if I just had a checkbox in ethereal that said 'FCS is last 4 
> bytes, always!'
> then ethereal would not have to parse any protocols to decode the FCS 
> correctly.

And if the protocols being used either run atop 802.3+802.2 or include 
a length field, Ethereal would not have to be *changed* to decode the 
FCS correctly.

The checkbox might be useful for other protocols, and for overriding 
Ethereal's default behavior, but it is *NOT* necessary for IPv4 or IPv6 
or IPX (they have length fields), or for a bunch of miscellaneous 
protocols that run atop 802.3+802.2.

> As mentioned, I'll try to get the feature into the Linux kernel so 
> that ethereal
> can automatically querry the interface when it starts its capture, 
> making
> the checkbox irrelevent (on these versions of Linux at least).

No, it doesn't - not unless there's something in the capture file to 
indicate whether a packet has an FCS or not (and note that, for 
outgoing packets, the answer is probably "not" regardless of whether 
the driver has been configured to include the FCS in *received* packets 
or not).