wireless: the contenders

First, the news everyone will like. Thanks to the kernel.org team I now have a place to publish a wireless tree:

git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git

The tree there has a number of branches, so many that you need a scorecard...

Branches
--------

The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus changes I recently sent to Jeff. Those changes are also available on the "upstream-jgarzik" branch, but it is frozen to when I requested Jeff's pull.

The tree also has "softmac" and "dscape" branches. The "softmac" branch includes the Johannes Berg softmac code as well as the the BCM43xx driver based upon that code. The "dscape" branch includes the DeviceScape patches from Jiri Benc as well as the BCM43xx driver ported to the DeviceScape stack.

The fact that the BCM43xx team has ported their driver to both stacks provides us an excellent opportunity for some objective, "apples to apples" comparisons between the major stacks. I would like to take this opportunity to thank them for taking the trouble to do that work and to make both versions available for comparison.

BTW, those trying to actually use the dscape code will want to poke around Jiri's kernel.org directories:

http://www.kernel.org/pub/linux/kernel/people/jbenc/

Jiri has some information there that will likely be useful to you.

The other branches are for administrative purposes, and can mostly be ignored.

Patches
-------

Along with bugfixes and enhancements to the current code (which will be targeting the "master" branch), I would like to see driver and stack patches for both the "softmac" and "dscape" branches. I would like to see what is really out there before making a final call on which stack to adopt permanently.

If you have an out-of-tree driver which targets either (or both) stacks, please send patches. If you are working on porting an in-kernel driver to one of these stacks (either from the other stack or from its private stack), please send patches. If you have fixes or enhancements pending for either of these stacks, then please send patches.

Don't waste any time with your patches. There is good reason to make a decision quickly, and plenty of pressure to do so. Your code could be a significant factor in making that decision.

I know that many of you believe that this approach is a bad idea, for a variety of reasons. I find those arguments valid, and even persuasive. The point of this exercise is NOT to push two stacks forward into Linus' kernel. The point is to catalog the true state of affairs and to collect as large a wireless driver codebase as possible. You might think of this as a Domesday Book
(http://en.wikipedia.org/wiki/Domesday_Book) for Linux wireless.

Summary
-------

Hopefully the act of collecting these patches will also allow the less motivated among us to have a chance to evaluate the stacks involved. There are bound to be some wise and skilled kernel hackers out there that are just a little too busy to track-down all these patches themselves... :-)

I appreciate all the commentary and ideas expressed over the past couple of weeks. I also think the driver writers are doing a good job with what they've been given so far. I hope this helps to bring the driver guys in out of the cold, and to put some weight behind the discussions of where we need to go.

Thanks,

John

John W. Linville
[email protected]

Are you going to keep it synced with our repository? I think it should be possible to automatically send patches for every change in our tree to you. I am not 100% sure (but 99%). I will look at it tomorrow.

Greetings Michael.

If you'll send me patches, I'll apply them...

John

P.S. Please do what you can to make them comply w/ kernel patch posting conventions:

http://linux.yyz.us/patch-format.html

John W. Linville
[email protected]

Minor git administrative note... In my trees, the 'master' branch is always vanilla Linus, and I never ever apply my own changes to it. This enables commands such as

git diff master..upstream > patch
git log master..upstream > log.txt
git log master..upstream | git shortlog > shortlog.txt

to work as expected.

Typically I do not update 'master' unless I am also updating 'upstream' with vanilla Linus changes, in order to avoid screwing up the tree heads and the diff. When I do update 'master' from 'upstream', it is a trivial matter to then pull those changes into 'upstream':

git checkout -f upstream
git pull . master

Regards,

Jeff

Good info...thanks!

FWIW, I have an "origin" branch that corresponds to Linus' tree. I think that probably enables the same kind of usage as you noted...?

Thanks,

John

John W. Linville
[email protected]

Yep, it doesn't matter what you call it.

I avoid 'origin' since a 'git pull' without arguments will automatically update that (and possibly master too).

But it's just a name. Any branch with vanilla Linus tree in it will achieve the behavior I described.

Jeff

I guess that branch also contains my enhancements to ieee80211, do you have any intentions of pulling those over to your upstream tree? I suppose I should rather post them as a series of patches to netdev for wider consideration.

johannes

I pulled from the softmac-2.6.git tree. I think there was ieee80211 stuff in there as well, but you probably know better than I do. :-)

The history in your tree isn't formatted properly for the kernel, so something would have to be done before that went upstream anyway. I think it would be best for you to post the patches to netdev, including patches covering softmac if you are so inclined. Please be sure to follow kernel patch posting conventions:

http://linux.yyz.us/patch-format.html

Thanks,

John

John W. Linville
[email protected]

Patch fixes misplaced (). Diffed against wireless-2.6.git

--
vda

diff -urpN softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
@@ -562,7 +562,7 @@ int ieee80211_rx(struct ieee80211_device
 	/* skb: hdr + (possibly fragmented) plaintext payload */
 	// PR: FIXME: hostap has additional conditions in the "if" below:
 	// ieee->host_decrypt && (fc & IEEE80211_FCTL_PROTECTED) &&
-	if ((frag != 0 || (fc & IEEE80211_FCTL_MOREFRAGS))) {
+	if ((frag != 0) || (fc & IEEE80211_FCTL_MOREFRAGS)) {
 		int flen;
 		struct sk_buff *frag_skb = ieee80211_frag_cache_get(ieee, hdr);
 		IEEE80211_DEBUG_FRAG("Rx Fragment received (%u)\n", frag);

bcm43xx_rx() contains code to filter out packets from foreign BSSes and decide whether to call ieee80211_rx or ieee80211_rx_mgt. This is not bcm specific.

Patch adapts that code and adds it to softmac as ieee80211_rx_any() function.

Diffed against wireless-2.6.git

--
vda

bcm43xx_rx() contains code to filter out packets from foreign BSSes and decide whether to call ieee80211_rx or ieee80211_rx_mgt. This is not bcm specific.

Patch adapts that code and adds it to softmac.

diff -urpN softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
@@ -758,6 +758,79 @@ int ieee80211_rx(struct ieee80211_device
 	/* Returning 0 indicates to caller that we have not handled the SKB--
 	 * so it is still allocated and can be used again by underlying
 	 * hardware as a DMA target */
+	return 0;
+}
+
+/* Kernel doesn't have it, why? */
+static inline int is_mcast_or_bcast_ether_addr(const u8 *addr)
+{
+        return (0x01 & addr[0]);
+}
+
+/* Filter out unrelated packets, call ieee80211_rx[_mgt] */
+int ieee80211_rx_any(struct ieee80211_device *ieee,
+		     struct sk_buff *skb, struct ieee80211_rx_stats *stats)
+{
+	struct ieee80211_hdr_4addr *hdr;
+	int is_packet_for_us;
+	u16 fc;
+
+	if (ieee->iw_mode == IW_MODE_MONITOR)
+		return ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL;
+
+	hdr = (struct ieee80211_hdr_4addr *)skb->data;
+	fc = le16_to_cpu(hdr->frame_ctl);
+
+	switch (fc & IEEE80211_FCTL_FTYPE) {
+	case IEEE80211_FTYPE_MGMT:
+		return ieee80211_rx_mgt(ieee, hdr, stats);
+	case IEEE80211_FTYPE_DATA:
+		break;
+	case IEEE80211_FTYPE_CTL:
+		return 0;
+	default:
+		return -EINVAL;
+	}
+
+	is_packet_for_us = 0;
+	switch (ieee->iw_mode) {
+	case IW_MODE_ADHOC:
+		/* promisc: get all */
+		if (ieee->dev->flags & IFF_PROMISC)
+			is_packet_for_us = 1;
+		/* our BSS */
+		else if (memcmp(hdr->addr3, ieee->bssid, ETH_ALEN) == 0) {
+			/* to us */
+			if (memcmp(hdr->addr1, ieee->dev->dev_addr, ETH_ALEN) == 0)
+				is_packet_for_us = 1;
+			/* mcast */
+			else if (is_mcast_or_bcast_ether_addr(hdr->addr1))
+				is_packet_for_us = 1;
+		}
+		break;
+	case IW_MODE_INFRA:
+		/* promisc: get all */
+		if (ieee->dev->flags & IFF_PROMISC)
+			is_packet_for_us = 1;
+		/* our BSS (== from our AP) */
+		else if (memcmp(hdr->addr2, ieee->bssid, ETH_ALEN) == 0) {
+			/* to us */
+			if (memcmp(hdr->addr1, ieee->dev->dev_addr, ETH_ALEN) == 0)
+				is_packet_for_us = 1;
+			/* mcast */
+			else if (is_mcast_or_bcast_ether_addr(hdr->addr1))
+				/* not our own packet bcasted from AP */
+				if (memcmp(hdr->addr3, ieee->dev->dev_addr, ETH_ALEN))
+					is_packet_for_us = 1;
+		}
+		break;
+	default:
+		/* ? */
+		break;
+	}
+
+	if (is_packet_for_us)
+		return (ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL);
 	return 0;
 }
 

bcm43xx_rx() contains code to filter out packets from foreign BSSes and decide whether to call ieee80211_rx or ieee80211_rx_mgt. This is not bcm specific.

Patch adapts that code and adds it to 80211
as ieee80211_rx_any() function.

Diffed against wireless-2.6.git

--
vda

diff -urp softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
@@ -758,6 +758,80 @@ int ieee80211_rx(struct ieee80211_device
 	/* Returning 0 indicates to caller that we have not handled the SKB--
 	 * so it is still allocated and can be used again by underlying
 	 * hardware as a DMA target */
+	return 0;
+}
+
+/* Kernel doesn't have it, why? */
+static inline int is_mcast_or_bcast_ether_addr(const u8 *addr)
+{
+        return (0x01 & addr[0]);
+}
+
+/* Filter out unrelated packets, call ieee80211_rx[_mgt] */
+int ieee80211_rx_any(struct ieee80211_device *ieee,
+		     struct sk_buff *skb, struct ieee80211_rx_stats *stats)
+{
+	struct ieee80211_hdr_4addr *hdr;
+	int is_packet_for_us;
+	u16 fc;
+
+	if (ieee->iw_mode == IW_MODE_MONITOR)
+		return ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL;
+
+	hdr = (struct ieee80211_hdr_4addr *)skb->data;
+	fc = le16_to_cpu(hdr->frame_ctl);
+
+	switch (fc & IEEE80211_FCTL_FTYPE) {
+	case IEEE80211_FTYPE_MGMT:
+		ieee80211_rx_mgt(ieee, hdr, stats);
+		return 0;
+	case IEEE80211_FTYPE_DATA:
+		break;
+	case IEEE80211_FTYPE_CTL:
+		return 0;
+	default:
+		return -EINVAL;
+	}
+
+	is_packet_for_us = 0;
+	switch (ieee->iw_mode) {
+	case IW_MODE_ADHOC:
+		/* promisc: get all */
+		if (ieee->dev->flags & IFF_PROMISC)
+			is_packet_for_us = 1;
+		/* our BSS */
+		else if (memcmp(hdr->addr3, ieee->bssid, ETH_ALEN) == 0) {
+			/* to us */
+			if (memcmp(hdr->addr1, ieee->dev->dev_addr, ETH_ALEN) == 0)
+				is_packet_for_us = 1;
+			/* mcast */
+			else if (is_mcast_or_bcast_ether_addr(hdr->addr1))
+				is_packet_for_us = 1;
+		}
+		break;
+	case IW_MODE_INFRA:
+		/* promisc: get all */
+		if (ieee->dev->flags & IFF_PROMISC)
+			is_packet_for_us = 1;
+		/* our BSS (== from our AP) */
+		else if (memcmp(hdr->addr2, ieee->bssid, ETH_ALEN) == 0) {
+			/* to us */
+			if (memcmp(hdr->addr1, ieee->dev->dev_addr, ETH_ALEN) == 0)
+				is_packet_for_us = 1;
+			/* mcast */
+			else if (is_mcast_or_bcast_ether_addr(hdr->addr1))
+				/* not our own packet bcasted from AP */
+				if (memcmp(hdr->addr3, ieee->dev->dev_addr, ETH_ALEN))
+					is_packet_for_us = 1;
+		}
+		break;
+	default:
+		/* ? */
+		break;
+	}
+
+	if (is_packet_for_us)
+		return (ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL);
 	return 0;
 }
 

Please ignore this one. This is not good:

+               return ieee80211_rx_mgt(ieee, hdr, stats);

Use corrected patch in my another email with
"Date: Sun, 22 Jan 2006 14:04:52 +0200"
--
vda

I would say, please also move the
static inline int is_mcast_or_bcast_ether_addr(const u8 *addr) function into linux/etherdevice.h

Greetings Michael.

Am Montag 23 Januar 2006 15:32 schrieb Johannes Berg:

no, management packets are used to populate f.e. scanning results.

Stefan

In wired networks promisc literally means "receive all packets", right?

But for wireless, maybe we should filter them out, or else running tcpdump on the iface will force us to listen to ARP packets from unrelated networks. That would be rather surprising and disrupting.
--
vda

Filtering on BSSID is necessary for management frames, especially when multicast management frames are thrown into the mix.

For example, STAs are supposed to respect broadcast disassoc/deauth messages, but of course should ignore them if they're not destined for the local BSSID.

The only extra-BSS management frames that should not be dropped are are beacons and probe responses. That said, probe responses are directed so our A1 (RA) filter will probably drop the frame if it is not destined for us.

- Solomon

Solomon Peachy        				 ICQ: 1318344
Melbourne, FL 					 
Quidquid latine dictum sit, altum viditur.

ieee80211_rx_mgt can do any filtering necessary.

Foreign mgmt packets, if properly used, can provide us with constantly updated info about local wireless neighborhood: available Ad-hoc networks and BSSes, signal quality of APs etc. Something resembling constantly running scan. For example, acx driver does exactly this.

Note that typically mgmt traffic is rather low and processing it (instead of dropping) won't add much overhead.

This filtering can (should) be done in ieee80211_rx_mgt.

--
vda