Re: Dealing with M_HASFCS for protocols that do not do ethernet crc

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> we recently saw a fix (for dev/ic/dwc_gmac.c) to one of the (10?)
> drivers that blindly set M_HASFCS on mbufs because their hardware
> does not strip the ethernet crc off automatically.

> The log message explains the issue well:

> ------------------------------------------------------------------------
> Do not unilaterally set M_HASFCS; this breaks protocols that lack CRC bytes
> (such as AppleTalk).
> [...]

Okay, I'm confused.  (I'm asking not because this is of practical
relevance to me, but rather because this indicates my understanding is
flawed and I'd like to correct that.)

I thought the frame check CRC was part of the Ethernet spec, and, as
such, was not an optional part of any Ethernet packet - on a par with
source and destination MACs or the two-byte next-protocol value.

But this seems to carry a contrary implication.  What's going on here?
Is my impression that the CRC is by definition a part of any Ethernet
packet wrong?  Or is the commit message talking about something else?
Or what?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B