Attached is a patch for include/linux/if_arp.h, which adds two new
ARPHRD types, ARPHRD_IEEE80211_FULL and ARPHRD_IEEE80211_CAPTURE.
This patch is against 2.4.20-pre8, but it should also go into 2.5.x as
well, assuming I'm not flamed into oblivion..
A bit of explanation. First, _FULL:
IEEE 802.11 has a variable "hardware" header length, 24 bytes for most
frames but 30 bytes for others. This poses a problem if you want to
expose a native 802.11 netdev interface to the OS, as
netdev->hardhdr_len et.al. aren't variable.
But wait, isn't there already ARPHRD_IEEE80211? Yes, but unfortunately,
common usage of this type assumes 24-byte headers. So if we break this
assumption, we break backwards compatibility with existing apps.
Remember this is intended for a native 802.11 netdev, and plenty of
stuff uses PF_PACKET sockets on these interfaces expecting packets to
come and go a certian way. For Rx frames we can play games with the
skb->mac.raw pointer, but this won't do for Tx frames.
Onto the _CAPTURE type.
(See http://www.shaftnet.org/~pizza/software/capturefrm.txt for the
longwinded version including the header format)
"The original header format for 'monitor mode' or capturing frames was
a considerable hack. The document covers a redesign of that format."
That "considerable hack" is ARPHRD_IEEE80211_PRISM, which has since come
to be used by many other drivers in lieu of a better way to do things.
Unfortunately, there is no version field in the old format, so for the
sake of making a clean break we'd like to get a new ARP type defined for
it.
This new header is non-hardware specific and has many more useful
fields, as well as the removal of a lot of cruft. And there's now
version and length fields, so we can expand on this format cleanly in
the future and not bother you guys with new ARPHRD types. :)
...
Nothing in the wild is currently using either of these types, but that
will change RSN.. and I can't push patches to libpcapðereal until the
ARP types are in the kernel and therefore fixed. :)
- Pizza
--
Solomon Peachy [email protected]
AbsoluteValue Systems http://www.linux-wlan.com
715-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
On Mon, 2002-10-21 at 15:19, Solomon Peachy wrote:
> IEEE 802.11 has a variable "hardware" header length, 24 bytes for most
> frames but 30 bytes for others. This poses a problem if you want to
> expose a native 802.11 netdev interface to the OS, as
> netdev->hardhdr_len et.al. aren't variable.
>
> But wait, isn't there already ARPHRD_IEEE80211? Yes, but unfortunately,
If ARPHRD_IEEE80211 assumes 24 bytes, and like you say it shouldn't,
fix that bug instead. Don't add new ARP header types just to put
a bandaid on another bug.
On Tue, Oct 22, 2002 at 04:55:36PM -0700, David S. Miller wrote:
> If ARPHRD_IEEE80211 assumes 24 bytes, and like you say it shouldn't,
> fix that bug instead. Don't add new ARP header types just to put
> a bandaid on another bug.
Oh, I completely agree. Unfortunately, the underlying problem is that
the IEEE 802.11 spec has a variable-length hardware header, and that's
not fixable, ruby slippers or no.
I admit that the 80211_FULL was the easy way out, so let me ramble on a
bit and perhaps you can correct and/or clue me in...
AFAIK, no driver currently exposes a native 802.11 interface to the os
(instead exposing ethernet and converting on the fly to 802.11). I'd
like to change this, eventually submitting an equivalent of the stuff in
net/ethernet/eth.c, perhaps as part of the wireless extensions.
hard_header_len is used on skb allocations to ensure we have enough
space for all of the various hardware headers without having to
reallocate/memcpy the skbs all over the place.
This would infer that we need to set hard_header_len to 30. On a
transmit, we'd pre-allocate this skb, then pass it off to hard_header to
add in the hardware header, then pass it on to the hard_start_xmit call.
So in the case of "cooked" transmits, hard_header_len+hard_header() can
be anything they want to be, and the ARP type doesn't need to change.
Enter AF_PACKET, and things get messier. According to the comments in
af_packet.c in 2.4.19, skb->mac.raw and skb->data are used for all
operations, both tx and rx, so they should be able to handle any header
length with no problems.
Now here's the crucual question. Because of this variable-length
header, (skb->mac.raw - skb->data != hard_header_len). My understanding
was that this (at least used to) cause problems. If this isn't the
case... then there's no reason to create a new ARPHRD type with a
max-fixed-length header.
Anyway, the native 802.11 OS interface is a ways off (mostly on paper
still), so there's plenty of time to work this out.
In the shorter run, do you have any objections to the creation of the
ARPHRD_IEEE80211_CAPTURE type? (and if not, what's the final number?)
Thanks!
- Pizza
--
Solomon Peachy [email protected]
AbsoluteValue Systems http://www.linux-wlan.com
715-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
On Wed, 2002-10-23 at 07:16, Solomon Peachy wrote:
> Oh, I completely agree. Unfortunately, the underlying problem is that
> the IEEE 802.11 spec has a variable-length hardware header, and that's
> not fixable, ruby slippers or no.
I'm not allowing you to put a hack special ARP header type into
the kernel when the real fix is to clean up the 802.11 handling
in the entire tree.
If that means every ethernet driver has to be aware of variable length
headers potentially, so be it.
This is the second time I'm saying this.
I'm not going to address the compression bits until you resolve this
and fix the problem properly instead of proposing hacks.
On Wed, Oct 23, 2002 at 09:18:00PM -0700, David S. Miller wrote:
> I'm not allowing you to put a hack special ARP header type into
> the kernel when the real fix is to clean up the 802.11 handling
> in the entire tree.
It's not so much a matter of "clean up" as "write to begin with"
> This is the second time I'm saying this.
And this is the second time I'm saying that I agree that it is the wrong
thing to do; I don't want to do it; I withdraw my request for the new
ARPHRD type; and again ask the question:
Do the network core &| protocol stacks have any dependencies on
(skb->mac.raw - skb->data) being the same as netdev->hard_header_len?
I'm asking you if the core networking stuff can handle variable-length
headers coming off of one netdev.
Can I assume it generally works, or is it generally broken? You seem to
be implying the latter.
> If that means every ethernet driver has to be aware of variable length
> headers potentially, so be it.
The ethernet drivers are not broken. The generic ethernet code is not
broken. 802.11 headers are not a "special case" of 802.[23] headers.
If anything is broken wrt variable headers, it would be net/ipv4 or
some other protocol stack.
So, what do you want me to do?
0) go away
1) audit the use of hard_header_len in net/* and submit fixes
2) write an 802.11 equivalent of the code in eth.c
3) mangle eth.c to handle 802.11 &| variable headers and fix all
drivers that inevitably break
Bleh.
- Pizza
--
Solomon Peachy [email protected]
AbsoluteValue Systems http://www.linux-wlan.com
715-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
On Thu, 2002-10-24 at 15:58, Solomon Peachy wrote:
> 1) audit the use of hard_header_len in net/* and submit fixes
We've handled variable length headers for years so that bit I do trust.
AX.25 even has variable length headers on ARP frames 8)
> 2) write an 802.11 equivalent of the code in eth.c
That may be much cleaner and easier to get right. Its also easier to
maintain
On Thu, Oct 24, 2002 at 04:38:56PM +0100, Alan Cox wrote:
> On Thu, 2002-10-24 at 15:58, Solomon Peachy wrote:
> > 1) audit the use of hard_header_len in net/* and submit fixes
> We've handled variable length headers for years so that bit I do trust.
And that's exactly what I wanted to know, thanks.
Out of curiousity, how far back to you trust the code? 2.2? 2.0? I only
ask because a lot of the driver work I do is for underpowered
embedded targets running relatively ancient 2.0 kernels.
> AX.25 even has variable length headers on ARP frames 8)
Eww.
> > 2) write an 802.11 equivalent of the code in eth.c
> That may be much cleaner and easier to get right. Its also easier to
> maintain
That's what I've been planning to do all along. It will be nice not
having to convert 802.3<-->802.11 in every wireless driver.. plus the
added benefit of not having to realloc/memcpy buffers to work around
dumb DMA engines that require contiguious buffers..
- Pizza
--
Solomon Peachy [email protected]
AbsoluteValue Systems http://www.linux-wlan.com
715-D North Drive +1 (321) 259-0737 (office)
Melbourne, FL 32934 +1 (321) 259-0286 (fax)
On Thu, 2002-10-24 at 16:53, Solomon Peachy wrote:
> Out of curiousity, how far back to you trust the code? 2.2? 2.0? I only
> ask because a lot of the driver work I do is for underpowered
> embedded targets running relatively ancient 2.0 kernels.
I trust it back to 2.2, Im not sure about 2.0 but its probably ok.
> > > 2) write an 802.11 equivalent of the code in eth.c
> > That may be much cleaner and easier to get right. Its also easier to
> > maintain
>
> That's what I've been planning to do all along. It will be nice not
> having to convert 802.3<-->802.11 in every wireless driver.. plus the
> added benefit of not having to realloc/memcpy buffers to work around
> dumb DMA engines that require contiguious buffers..
Remember that you want to land IP frame headers on a 4 byte boundary if
possible. Thats sometimes a conflicting constraint alas