mac80211 rx filter in mesh mode, rt2x00 mesh point operation

RFC In review Andrey Yurovsky 4 participants 11 messages Oct 23, 2008 – Oct 30, 2008 Networking drivers (wireless)

Share & tools

Andrey Yurovsky

author

2008-10-23 21:49 UTC #0 lore raw

RFC 1/1 mac80211 rx filter in mesh mode, rt2x00 mesh point operation

I've come across a problem with the RX filter setting while testing mesh point operation in the rt2x00 driver (my hardware is rt73usb). We transmit and receive mesh beacons but mesh peer link action frames are dropped. A patch for enabling mesh point mode is included here, this works except that:

The RX filter, as set by mac80211 in mesh mode is 0x02, that is FIF_ALLMULTI is set. This is sufficient for other drivers but not for rt2x00. I noticed that running tcpdump on the MP interface sets the filter to 0x43, this adds FIF_OTHER_BSS and FIF_PROMISC_IN_BSS, and rt2x00 is then able to make peer links and mesh point mode works correctly.

Actually for rt2x00, setting either FIF_OTHER_BSS or FIF_PROMISC_IN_BSS is the key here because they are both treated as FIF_PROMISC_IN_BSS, which causes the driver to enable TXRX_CSR0_DROP_TO_DS.

To solve this problem, it seems that we can either:
1. change the RX filter specified in mesh point mode. I am concerned that this would pass up unnecessary frames to the other drivers which otherwise work fine with just FIF_ALLMULTI set. Are there any opinions on this?
2. modify the rt2x00 rx filter setting implementation to set additional flags, possibly with knowledge that the interface is in mesh point mode. This seems hacky as the filter setting is supposed to be fairly generic.
3. revisit the setting of TXRX_CSR0_DROP_TO_DS and possibly other bits in the HW rx filter, CCing Ivo regarding this.

drivers/net/wireless/rt2x00/rt2x00config.c +1 -0

index 7910147..3021c2a 100644
@@ -42,6 +42,7 @@ void rt2x00lib_config_intf(struct rt2x00_dev *rt2x00dev,
 	switch (type) {
 	case NL80211_IFTYPE_ADHOC:
 	case NL80211_IFTYPE_AP:
+	case NL80211_IFTYPE_MESH_POINT:
 		conf.sync = TSF_SYNC_BEACON;
 		break;
 	case NL80211_IFTYPE_STATION:

drivers/net/wireless/rt2x00/rt2x00dev.c +7 -4

index 697806c..2b9d0a0 100644
@@ -466,7 +466,8 @@ static void rt2x00lib_beacondone_iter(void *data, u8 *mac,
 	struct rt2x00_intf *intf = vif_to_intf(vif);
 
 	if (vif->type != NL80211_IFTYPE_AP &&
-	    vif->type != NL80211_IFTYPE_ADHOC)
+	    vif->type != NL80211_IFTYPE_ADHOC &&
+	    vif->type != NL80211_IFTYPE_MESH_POINT)
 		return;
 
 	/*

@@ -1053,7 +1054,8 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
 	rt2x00dev->hw->wiphy->interface_modes =
 	    BIT(NL80211_IFTYPE_AP) |
 	    BIT(NL80211_IFTYPE_STATION) |
-	    BIT(NL80211_IFTYPE_ADHOC);
+	    BIT(NL80211_IFTYPE_ADHOC) |
+	    BIT(NL80211_IFTYPE_MESH_POINT);
 
 	/*
 	 * Let the driver probe the device to detect the capabilities.

@@ -1208,10 +1210,11 @@ static void rt2x00lib_resume_intf(void *data, u8 *mac,
 
 
 	/*
-	 * Master or Ad-hoc mode require a new beacon update.
+	 * Master, Ad-hoc, or Mesh Point mode require a new beacon update.
 	 */
 	if (vif->type == NL80211_IFTYPE_AP ||
-	    vif->type == NL80211_IFTYPE_ADHOC)
+	    vif->type == NL80211_IFTYPE_ADHOC ||
+	    vif->type == NL80211_IFTYPE_MESH_POINT)
 		intf->delayed_flags |= DELAYED_UPDATE_BEACON;
 
 	spin_unlock(&intf->lock);

drivers/net/wireless/rt2x00/rt2x00mac.c +1 -0

index da7b49a..d4bd072 100644
@@ -229,6 +229,7 @@ int rt2x00mac_add_interface(struct ieee80211_hw *hw,
 		break;
 	case NL80211_IFTYPE_STATION:
 	case NL80211_IFTYPE_ADHOC:
+	case NL80211_IFTYPE_MESH_POINT:
 		/*
 		 * We don't support mixed combinations of
 		 * sta and ap interfaces.

Javier Cardona

2008-10-23 22:07 UTC #1 lore raw

Andrey,

On Thu, Oct 23, 2008 at 2:49 PM, Andrey Yurovsky <[email protected]> w= rote:

Quoted 1 line

I've come across a problem with the RX filter setting while testing m=

esh point

Quoted 1 line

operation in the rt2x00 driver (my hardware is rt73usb). We transmit=

and

Quoted 1 line

receive mesh beacons but mesh peer link action frames are dropped. A=

patch

Quoted 1 line

for enabling mesh point mode is included here, this works except that=

Quoted 2 lines

The RX filter, as set by mac80211 in mesh mode is 0x02, that is FIF_A=

LLMULTI is

Quoted 1 line

set. This is sufficient for other drivers but not for rt2x00. I not=

iced that

Quoted 1 line

running tcpdump on the MP interface sets the filter to 0x43, this add=

Quoted 1 line

FIF_OTHER_BSS and FIF_PROMISC_IN_BSS, and rt2x00 is then able to make=

peer

Quoted 3 lines

links and mesh point mode works correctly.
Actually for rt2x00, setting either FIF_OTHER_BSS or FIF_PROMISC_IN_B=

SS is the

Quoted 1 line

key here because they are both treated as FIF_PROMISC_IN_BSS, which c=

auses the

Quoted 1 line

driver to enable TXRX_CSR0_DROP_TO_DS.

Mesh frames have 4 addresses and no BSSID, so BSSID filtering should be disabled (i.e. FIF_OTHER_BSS should be set).
The ALL_MULTI flag is also needed for mesh mode because an intermediate node has to forward multicast traffic for addresses that it may not be listening to.

But promiscuous mode is not necessary: mesh points don't need to receive unicast frames not addressed=B9 to them. Furthermore, enabling promiscuous mode normally disables acknowledgments, which are needed for proper mesh operation.

So my recommendation would be to configure the RX filter in mesh mode to be ( FIF_ALLMULTI | FIF_OTHER_BSS )

Cheers,

Javier

[1] By addressed I mean that the node's address is in the first address field, RA, not necessarily in the DA.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Johannes Berg

maintainer

2008-10-24 09:54 UTC #2 lore raw

Javier,

Quoted 2 lines · Javier Cardona

Mesh frames have 4 addresses and no BSSID, so BSSID filtering should be disabled (i.e. FIF_OTHER_BSS should be set).

The BSSID is zeroed, right?

Quoted 11 lines

The ALL_MULTI flag is also needed for mesh mode because an intermediate node has to forward multicast traffic for addresses that it may not be listening to.
But promiscuous mode is not necessary: mesh points don't need to receive unicast frames not addressed¹ to them. Furthermore, enabling promiscuous mode normally disables acknowledgments, which are needed for proper mesh operation.
So my recommendation would be to configure the RX filter in mesh mode to be ( FIF_ALLMULTI | FIF_OTHER_BSS )

I agree, mesh really has no concept of a BSS so it shouldn't try to filter on the BSSID.

johannes

Javier Cardona

2008-10-24 17:05 UTC #3 lore raw

Johannes,

Quoted 7 lines · Johannes Berg

Javier,
Quoted 2 lines · Javier Cardona
Mesh frames have 4 addresses and no BSSID, so BSSID filtering should be disabled (i.e. FIF_OTHER_BSS should be set).
The BSSID is zeroed, right?

On data frames or multi-hop management frames there is no BSSID address. On single-hop management frames the BSSID field is not used and set to all zeros.

Cheers,

Javier

Ivo van Doorn

2008-10-25 10:28 UTC #4 lore raw

In reply to Javier Cardona

Quoted 3 lines · Javier Cardona

Andrey,
=20
On Thu, Oct 23, 2008 at 2:49 PM, Andrey Yurovsky <[email protected]>=

Quoted 1 line · wrote:

Quoted 1 line
I've come across a problem with the RX filter setting while testing=

mesh point

Quoted 1 line

Quoted 1 line
operation in the rt2x00 driver (my hardware is rt73usb). We transm=

it and

Quoted 1 line

Quoted 1 line
receive mesh beacons but mesh peer link action frames are dropped. =

A patch

Quoted 1 line

Quoted 1 line
for enabling mesh point mode is included here, this works except th=

at:

Quoted 2 lines

Quoted 2 lines
The RX filter, as set by mac80211 in mesh mode is 0x02, that is FIF=

_ALLMULTI is

Quoted 1 line

Quoted 1 line
set. This is sufficient for other drivers but not for rt2x00. I n=

oticed that

Quoted 1 line

Quoted 1 line
running tcpdump on the MP interface sets the filter to 0x43, this a=

dds

Quoted 1 line

Quoted 1 line
FIF_OTHER_BSS and FIF_PROMISC_IN_BSS, and rt2x00 is then able to ma=

ke peer

Quoted 3 lines

Quoted 3 lines
links and mesh point mode works correctly.
Actually for rt2x00, setting either FIF_OTHER_BSS or FIF_PROMISC_IN=

_BSS is the

Quoted 1 line

Quoted 1 line
key here because they are both treated as FIF_PROMISC_IN_BSS, which=

causes the

Quoted 10 lines

Quoted 1 line
driver to enable TXRX_CSR0_DROP_TO_DS.
=20
Mesh frames have 4 addresses and no BSSID, so BSSID filtering should be disabled (i.e. FIF_OTHER_BSS should be set).
The ALL_MULTI flag is also needed for mesh mode because an intermediate node has to forward multicast traffic for addresses that it may not be listening to.
=20
But promiscuous mode is not necessary: mesh points don't need to receive unicast frames not addressed=B9 to them. Furthermore, enabli=

Quoted 5 lines

promiscuous mode normally disables acknowledgments, which are needed for proper mesh operation.
=20
So my recommendation would be to configure the RX filter in mesh mode to be ( FIF_ALLMULTI | FIF_OTHER_BSS )

=46or rt2x00 this would turn into:
FIF_ALLMULTI | FIF_OTHER_BSS | FIF_PROMISC_IN_BSS

because it cannot filter on other BSS, but this conversion is within rt= 2x00
based on capabilities by the driver. So as long as mac80211 provides th= e flags
it wants (FIF_ALLMULTI | FIF_OTHER_BSS), rt2x00 will convert it to the = flags that
make sure those frames will at least get through (FIF_ALLMULTI | FIF_OT= HER_BSS | FIF_PROMISC_IN_BSS),
including some additional noise from frames mac80211 didn't request spe= cifically,
but those can be filtered out in mac80211.

Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Javier Cardona

2008-10-26 01:20 UTC #5 lore raw

Ivo,

Quoted 2 lines · Ivo van Doorn

For rt2x00 this would turn into:
FIF_ALLMULTI | FIF_OTHER_BSS | FIF_PROMISC_IN_BSS

With the above configuration, will the rt2x00 device acknowledge 1) unicast frames addressed to itself? 2) unicast frames addressed to others? 3) none of the above?

Thanks,

Javier

Johannes Berg

maintainer

2008-10-26 08:09 UTC #6 lore raw

Quoted 9 lines · Javier Cardona

Ivo,
Quoted 2 lines · Ivo van Doorn
For rt2x00 this would turn into:
FIF_ALLMULTI | FIF_OTHER_BSS | FIF_PROMISC_IN_BSS
With the above configuration, will the rt2x00 device acknowledge 1) unicast frames addressed to itself? 2) unicast frames addressed to others? 3) none of the above?

It should always only be (1), mac80211 might set OTHER_BSS if it (well, the user) wants to see traffic on the same channel from other BSSes.

johannes

Ivo van Doorn

2008-10-26 08:38 UTC #7 lore raw

Quoted 7 lines · Johannes Berg

Quoted 6 lines · Javier Cardona
Ivo,
Quoted 2 lines · Ivo van Doorn
For rt2x00 this would turn into:
FIF_ALLMULTI | FIF_OTHER_BSS | FIF_PROMISC_IN_BSS

Quoted 6 lines

Quoted 3 lines
With the above configuration, will the rt2x00 device acknowledge 1) unicast frames addressed to itself? 2) unicast frames addressed to others? 3) none of the above?
It should always only be (1), mac80211 might set OTHER_BSS if it (well, the user) wants to see traffic on the same channel from other BSSes.

As far as I know, rt2x00 devices will only do (1).

Ivo

Javier Cardona

2008-10-26 20:34 UTC #8 lore raw

In reply to Johannes Berg

Johannes, Ivo,

Quoted 7 lines · Johannes Berg

Quoted 6 lines · Javier Cardona
Ivo,
Quoted 2 lines · Ivo van Doorn
For rt2x00 this would turn into:
FIF_ALLMULTI | FIF_OTHER_BSS | FIF_PROMISC_IN_BSS

Quoted 6 lines

Quoted 3 lines
With the above configuration, will the rt2x00 device acknowledge 1) unicast frames addressed to itself? 2) unicast frames addressed to others? 3) none of the above?
It should always only be (1), mac80211 might set OTHER_BSS if it (well, the user) wants to see traffic on the same channel from other BSSes.

Good. My concern was that FIF_PROMISC_IN_BSS would disable all acknowledgments. (I've seen some wireless hw with that behavior)

Thanks!

Signature · 2 lines

Javier Cardona
cozybit Inc.

Johannes Berg

maintainer

2008-10-30 14:24 UTC #9 lore raw

Quoted 7 lines · Javier Cardona

Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
For rt2x00 this would turn into:
FIF_ALLMULTI | FIF_OTHER_BSS | FIF_PROMISC_IN_BSS
With the above configuration, will the rt2x00 device acknowledge 1) unicast frames addressed to itself? 2) unicast frames addressed to others? 3) none of the above?

Quoted 5 lines

Quoted 2 lines
It should always only be (1), mac80211 might set OTHER_BSS if it (well, the user) wants to see traffic on the same channel from other BSSes.
Good. My concern was that FIF_PROMISC_IN_BSS would disable all acknowledgments. (I've seen some wireless hw with that behavior)

Just for the record, (1) is the behaviour mac80211 needs, and hardware that behaves as the one you've seen wouldn't support FIF_PROMISC_IN_BSS at all, and consequently not mesh either, I suppose. I'll add a note to the API page.

johannes

Johannes Berg

maintainer

2008-10-30 14:31 UTC #10 lore raw

Quoted 12 lines · Johannes Berg

Quoted 10 lines · Javier Cardona
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
For rt2x00 this would turn into:
FIF_ALLMULTI | FIF_OTHER_BSS | FIF_PROMISC_IN_BSS
With the above configuration, will the rt2x00 device acknowledge 1) unicast frames addressed to itself? 2) unicast frames addressed to others? 3) none of the above?
It should always only be (1), mac80211 might set OTHER_BSS if it (well, the user) wants to see traffic on the same channel from other BSSes.

Quoted 7 lines

Quoted 2 lines
Good. My concern was that FIF_PROMISC_IN_BSS would disable all acknowledgments. (I've seen some wireless hw with that behavior)
Just for the record, (1) is the behaviour mac80211 needs, and hardware that behaves as the one you've seen wouldn't support FIF_PROMISC_IN_BSS at all, and consequently not mesh either, I suppose. I'll add a note to the API page.

Uh, I suppose we both meant FIF_OTHER_BSS. I did, at least.

johannes