On Sat, 15 May 1999 08:26:13 -0700 
 Matt Thomas <matt@3am-software.com> wrote:

 > Out of curiousity, what protocol?

PPP Over Ethernet (RFC 2516).  pppd(8) has one socket for the IPCP/LCP/etc.
packets anbd the PPPoE Discovery packets.  PPPoE Session and Discovery
packets use different Ethertypes.  pppd(8) needs to be able to choose the
correct code path for incoming packets, etc.

Basically, the application is like using Raw IP with IP_HDRINCL, except it
happens at layer 2.

The idea here is that for ETHERTYPE_PPPOE and ETHERTYPE_PPPOEDISC,
ether_input() will NOT m_adj() past the Ethernet header.

 > What about the CRC?  Should it be included as well (possibly as an optional
 > flag)?  (Think bridging)

I think we could allocate an M_LINKx flag for that, in Ethernet.  And
possibly ALWAYS have drivers include the CRC if possible.  If M_CRC
is set in the incoming packet, ether_input() can subtract ETHER_CRC_LEN
from the pkthdr.len and clear the flag, if appropriate.  If M_CRC is
included on output (in the driver start routine), the driver instructs
the chip to not generate CRC for that packet.

For chips which cannot per-packet control CRC generation, we could either
error out (or drop the packet, and log it?), or allow the chip to generate
the CRC after trimming it (and log it).

 > When you do this, how about making the xxx_input functions static?

Ah, good idea (output, too).

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>