Subject: Re: revised ethernet/802.xx input header processing.
To: Jason Thorpe <email@example.com>
From: Bill Sommerfeld <firstname.lastname@example.org>
Date: 10/30/1999 23:37:09
> Yes! Having the caller adjust the mbuf defeats the entire purpose
> of the changes I made earlier that cause the hardware drivers to not
> adjust the mbuf :-)
This is for PPPoE support, right? (you need access to the mac level
src/destination addresses there, right?)
PPPoE over 802.11 could get entertaining -- base stations are
typically bridges, but since 802.11 uses a different frame header, the
mac-layer addresses of interest to PPPoE won't be where you "expect"
them to be in the header.
802.11 frames start with 4 bytes of control information, including a
packet type, followed by 3 6-byte MAC addresses, followed by another 2
bytes of control info, followed by a LLC header.
the first two mac addresses are the wireless destination and wireless
source addresses. depending on the values of two of the control bits,
the third address is either the off-wireless-segment source, the
off-wireless-segment destination, or (for an ad-hoc peer-to-peer lan),
the ad-hoc wireless network number.
To make life even more entertaining, the MAC addresses of interest to
a PPPoE implementation will be in different places in the header
depending on whether the packet was sent from an ad-hoc peer or from a
Would passing pointers to src and dst addresses give PPPoE what it