wireless: the contenders

wireless: the contenders

[John W. Linville]

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
linville@tuxdriver.com

Re: [Bcm43xx-dev] wireless: the contenders

[Michael Buesch]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

On Wednesday 18 January 2006 21:06, John W. Linville wrote:
> 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.

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Bcm43xx-dev] wireless: the contenders

[John W. Linville]

On Wed, Jan 18, 2006 at 09:19:20PM +0100, Michael Buesch wrote:
> On Wednesday 18 January 2006 21:06, John W. Linville wrote:
> > 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.
> 
> 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.

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
linville@tuxdriver.com

Re: wireless: the contenders

[Jeff Garzik]

John W. Linville wrote:
> 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.

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

Re: wireless: the contenders

[John W. Linville]

On Wed, Jan 18, 2006 at 03:36:59PM -0500, Jeff Garzik wrote:
> John W. Linville wrote:

> >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.

> 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':

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
linville@tuxdriver.com

Re: wireless: the contenders

[Jeff Garzik]

On Wed, Jan 18, 2006 at 03:48:49PM -0500, John W. Linville wrote:
> On Wed, Jan 18, 2006 at 03:36:59PM -0500, Jeff Garzik wrote:
> > John W. Linville wrote:
> 
> > >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.
> 
> > 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':
> 
> 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...?

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

Re: [Bcm43xx-dev] wireless: the contenders

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On Wed, 2006-01-18 at 15:06 -0500, John W. Linville wrote:

> 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.

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [Bcm43xx-dev] wireless: the contenders

[John W. Linville]

On Thu, Jan 19, 2006 at 01:19:40AM +0100, Johannes Berg wrote:
> On Wed, 2006-01-18 at 15:06 -0500, John W. Linville wrote:
> 
> > 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.
> 
> 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.

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
linville@tuxdriver.com

[PATCH] trivial fix

[Denis Vlasenko]

[-- Attachment #1: Type: text/plain, Size: 116 bytes --]

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

Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
--
vda

[-- Attachment #2: trivial.patch --]
[-- Type: text/x-diff, Size: 761 bytes --]

diff -urpN softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c	Wed Jan 18 07:27:03 2006
+++ softmac-snapshot.1/net/ieee80211/ieee80211_rx.c	Sun Jan 22 13:12:30 2006
@@ -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);

[PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt

[Denis Vlasenko]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

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

Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
--
vda

[-- Attachment #2: rx.patch --]
[-- Type: text/x-diff, Size: 2655 bytes --]

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
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c	Wed Jan 18 07:27:03 2006
+++ softmac-snapshot.1/net/ieee80211/ieee80211_rx.c	Sun Jan 22 13:12:30 2006
@@ -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;
 }
 

Re: [Bcm43xx-dev] Re: [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt

[Michael Buesch]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Sunday 22 January 2006 13:08, Denis Vlasenko wrote:
> On Sunday 22 January 2006 13:59, Denis Vlasenko wrote:
> > 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
> > 
> > Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
> > --
> > vda
> 
> 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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt

[Denis Vlasenko]

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

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

Signed-off-by: Denis Vlasenko <vda@ilport.com.ua>
--
vda

[-- Attachment #2: rx.patch --]
[-- Type: text/x-diff, Size: 2456 bytes --]

diff -urp softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c	Wed Jan 18 07:27:03 2006
+++ softmac-snapshot.1/net/ieee80211/ieee80211_rx.c	Sun Jan 22 14:01:43 2006
@@ -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;
 }
 

Re: [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt

[Patrick McHardy]

Denis Vlasenko wrote:
> 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.
> 
> +/* Kernel doesn't have it, why? */
> +static inline int is_mcast_or_bcast_ether_addr(const u8 *addr)
> +{
> +        return (0x01 & addr[0]);
> +}

The same function exists in include/linux/etherdevice.h:

static inline int is_multicast_ether_addr(const u8 *addr)
{
        return (0x01 & addr[0]);
}

Re: [softmac-dev] [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

On Sun, 2006-01-22 at 14:04 +0200, Denis Vlasenko wrote:
> +       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;: 

Shouldn't you BSS-filter management packets too?

> +       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;

And I still think BSS-filtering is correct even in the promisc case. Any
other opinions why either way is right or not? [I think we should filter
because upper layers won't know the packet wasn't for us if it was
broadcast in another BSSID]

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [softmac-dev] [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt

[Stefan Rompf]

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

> Shouldn't you BSS-filter management packets too?

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

Stefan

Re: [Bcm43xx-dev] Re: [softmac-dev] [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt

[Denis Vlasenko]

On Monday 23 January 2006 16:32, Johannes Berg wrote:
> On Sun, 2006-01-22 at 14:04 +0200, Denis Vlasenko wrote:
> > +       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;: 
> 
> Shouldn't you BSS-filter management packets too?
> 
> > +       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;
> 
> And I still think BSS-filtering is correct even in the promisc case. Any
> other opinions why either way is right or not? [I think we should filter
> because upper layers won't know the packet wasn't for us if it was
> broadcast in another BSSID]

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

Re: [softmac-dev] [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt

[Stuffed Crust]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

On Mon, Jan 23, 2006 at 03:32:32PM +0100, Johannes Berg wrote:
> Shouldn't you BSS-filter management packets too?

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [softmac-dev] [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt

[Denis Vlasenko]

On Wednesday 25 January 2006 17:44, Stuffed Crust wrote:
> On Mon, Jan 23, 2006 at 03:32:32PM +0100, Johannes Berg wrote:
> > Shouldn't you BSS-filter management packets too?
> 
> Filtering on BSSID is necessary for management frames, especially when 
> multicast management frames are thrown into the mix.  

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.
 
> 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. 

This filtering can (should) be done in ieee80211_rx_mgt.

> 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.
--
vda