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.
diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c b/drivers/net/wireless/rt2x00/rt2x00config.c
index 7910147..3021c2a 100644
--- a/drivers/net/wireless/rt2x00/rt2x00config.c
+++ b/drivers/net/wireless/rt2x00/rt2x00config.c
@@ -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:
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 697806c..2b9d0a0 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -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);
diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c
index da7b49a..d4bd072 100644
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c
@@ -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.
Andrey,
On Thu, Oct 23, 2008 at 2:49 PM, Andrey Yurovsky <[email protected]> w=
rote:
> I've come across a problem with the RX filter setting while testing m=
esh 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_A=
LLMULTI is
> set. This is sufficient for other drivers but not for rt2x00. I not=
iced that
> running tcpdump on the MP interface sets the filter to 0x43, this add=
s
> 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_B=
SS is the
> key here because they are both treated as FIF_PROMISC_IN_BSS, which c=
auses the
> 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.
Johannes, Ivo,
On Sun, Oct 26, 2008 at 1:09 AM, Johannes Berg
<[email protected]> wrote:
> On Sat, 2008-10-25 at 18:20 -0700, Javier Cardona wrote:
>> Ivo,
>>
>> On Sat, Oct 25, 2008 at 3:28 AM, Ivo van Doorn <[email protected]> wrote:
>> > 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.
Good. My concern was that FIF_PROMISC_IN_BSS would disable all
acknowledgments. (I've seen some wireless hw with that behavior)
Thanks!
--
Javier Cardona
cozybit Inc.
On Sat, 2008-10-25 at 18:20 -0700, Javier Cardona wrote:
> Ivo,
>
> On Sat, Oct 25, 2008 at 3:28 AM, Ivo van Doorn <[email protected]> wrote:
> > 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
Johannes,
On Fri, Oct 24, 2008 at 2:02 AM, Johannes Berg
<[email protected]> wrote:
> Javier,
>
> On Thu, 2008-10-23 at 15:07 -0700, Javier Cardona wrote:
>> 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
On Sunday 26 October 2008, Johannes Berg wrote:
> On Sat, 2008-10-25 at 18:20 -0700, Javier Cardona wrote:
> > Ivo,
> >
> > On Sat, Oct 25, 2008 at 3:28 AM, Ivo van Doorn <[email protected]> wrote:
> > > 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.
As far as I know, rt2x00 devices will only do (1).
Ivo
Ivo,
On Sat, Oct 25, 2008 at 3:28 AM, Ivo van Doorn <[email protected]> wrote:
> 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
On Friday 24 October 2008, Javier Cardona wrote:
> Andrey,
>=20
> On Thu, Oct 23, 2008 at 2:49 PM, Andrey Yurovsky <[email protected]>=
wrote:
> > 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 transm=
it 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 th=
at:
> >
> > 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 n=
oticed that
> > running tcpdump on the MP interface sets the filter to 0x43, this a=
dds
> > FIF_OTHER_BSS and FIF_PROMISC_IN_BSS, and rt2x00 is then able to ma=
ke 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.
>=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=
ng
> 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
Javier,
On Thu, 2008-10-23 at 15:07 -0700, Javier Cardona wrote:
> 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?
> 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
On Sun, 2008-10-26 at 13:34 -0700, Javier Cardona wrote:
> >> > 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.
>
> 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
On Thu, 2008-10-30 at 13:26 +0100, Johannes Berg wrote:
> On Sun, 2008-10-26 at 13:34 -0700, Javier Cardona wrote:
>
> > >> > 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.
> >
> > 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