New ARPHRD types

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&ethereal 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)

@@ -83,6 +83,8 @@
 #define ARPHRD_IEEE802_TR 800		/* Magic type ident for TR	*/
 #define ARPHRD_IEEE80211 801		/* IEEE 802.11			*/
 #define ARPHRD_IEEE80211_PRISM 802	/* IEEE 802.11 + Prism2 header  */
+#define ARPHRD_IEEE80211_FULL  803	/* IEEE 802.11 w/ fixed headerlen */
+#define ARPHRD_IEEE80211_CAPTURE 804	/* IEEE 802.11 w/ new capture header */
 
 #define ARPHRD_VOID	  0xFFFF	/* Void type, nothing is known */
 

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)

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.

It's not so much a matter of "clean up" as "write to begin with"

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.

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)

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)

That may be much cleaner and easier to get right. Its also easier to maintain

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.

Eww.

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)

I trust it back to 2.2, Im not sure about 2.0 but its probably ok.

Remember that you want to land IP frame headers on a 4 byte boundary if possible. Thats sometimes a conflicting constraint alas