The TO_DS filter does not only depend on the FIF_PROMISC_IN_BSS flag
provided by mac80211, but also on the intf_ap_count count.
This makes sense, since when Master mode is active, we should all frames
that are send to the active AP (the device itself).
This means that when an interface is added we should force the
packet filter to be updated during the next mac80211 call of
configure_filter() to make sure the intf_ap_count field is checked.
Signed-off-by: Ivo van Doorn <[email protected]>
---
drivers/net/wireless/rt2x00/rt2400pci.c | 3 ++-
drivers/net/wireless/rt2x00/rt2500pci.c | 3 ++-
drivers/net/wireless/rt2x00/rt2500usb.c | 3 ++-
drivers/net/wireless/rt2x00/rt2x00mac.c | 7 +++++++
drivers/net/wireless/rt2x00/rt61pci.c | 3 ++-
drivers/net/wireless/rt2x00/rt73usb.c | 3 ++-
6 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c
index a6e9c89..9abdfb8 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -290,7 +290,8 @@ static void rt2400pci_config_filter(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(®, RXCSR0_DROP_NOT_TO_ME,
!(filter_flags & FIF_PROMISC_IN_BSS));
rt2x00_set_field32(®, RXCSR0_DROP_TODS,
- !(filter_flags & FIF_PROMISC_IN_BSS));
+ !(filter_flags & FIF_PROMISC_IN_BSS) &&
+ !rt2x00dev->intf_ap_count);
rt2x00_set_field32(®, RXCSR0_DROP_VERSION_ERROR, 1);
rt2x00pci_register_write(rt2x00dev, RXCSR0, reg);
}
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 1bdb873..54c9a75 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -291,7 +291,8 @@ static void rt2500pci_config_filter(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(®, RXCSR0_DROP_NOT_TO_ME,
!(filter_flags & FIF_PROMISC_IN_BSS));
rt2x00_set_field32(®, RXCSR0_DROP_TODS,
- !(filter_flags & FIF_PROMISC_IN_BSS));
+ !(filter_flags & FIF_PROMISC_IN_BSS) &&
+ !rt2x00dev->intf_ap_count);
rt2x00_set_field32(®, RXCSR0_DROP_VERSION_ERROR, 1);
rt2x00_set_field32(®, RXCSR0_DROP_MCAST,
!(filter_flags & FIF_ALLMULTI));
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index f5c18f0..28fdf19 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -337,7 +337,8 @@ static void rt2500usb_config_filter(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field16(®, TXRX_CSR2_DROP_NOT_TO_ME,
!(filter_flags & FIF_PROMISC_IN_BSS));
rt2x00_set_field16(®, TXRX_CSR2_DROP_TODS,
- !(filter_flags & FIF_PROMISC_IN_BSS));
+ !(filter_flags & FIF_PROMISC_IN_BSS) &&
+ !rt2x00dev->intf_ap_count);
rt2x00_set_field16(®, TXRX_CSR2_DROP_VERSION_ERROR, 1);
rt2x00_set_field16(®, TXRX_CSR2_DROP_MULTICAST,
!(filter_flags & FIF_ALLMULTI));
diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c
index a0adf5a..dc70e7a 100644
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c
@@ -253,6 +253,13 @@ int rt2x00mac_add_interface(struct ieee80211_hw *hw,
*/
rt2x00lib_config_intf(rt2x00dev, intf, conf->type, intf->mac, NULL);
+ /*
+ * Some filters depend on the current working mode. We can force
+ * an update during the next configure_filter() run by mac80211 by
+ * resetting the current packet_filter state.
+ */
+ rt2x00dev->packet_filter = 0;
+
return 0;
}
EXPORT_SYMBOL_GPL(rt2x00mac_add_interface);
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index 0d2e6f7..c5c6251 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -342,7 +342,8 @@ static void rt61pci_config_filter(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(®, TXRX_CSR0_DROP_NOT_TO_ME,
!(filter_flags & FIF_PROMISC_IN_BSS));
rt2x00_set_field32(®, TXRX_CSR0_DROP_TO_DS,
- !(filter_flags & FIF_PROMISC_IN_BSS));
+ !(filter_flags & FIF_PROMISC_IN_BSS) &&
+ !rt2x00dev->intf_ap_count);
rt2x00_set_field32(®, TXRX_CSR0_DROP_VERSION_ERROR, 1);
rt2x00_set_field32(®, TXRX_CSR0_DROP_MULTICAST,
!(filter_flags & FIF_ALLMULTI));
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index b3c8462..796cf29 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -354,7 +354,8 @@ static void rt73usb_config_filter(struct rt2x00_dev *rt2x00dev,
rt2x00_set_field32(®, TXRX_CSR0_DROP_NOT_TO_ME,
!(filter_flags & FIF_PROMISC_IN_BSS));
rt2x00_set_field32(®, TXRX_CSR0_DROP_TO_DS,
- !(filter_flags & FIF_PROMISC_IN_BSS));
+ !(filter_flags & FIF_PROMISC_IN_BSS) &&
+ !rt2x00dev->intf_ap_count);
rt2x00_set_field32(®, TXRX_CSR0_DROP_VERSION_ERROR, 1);
rt2x00_set_field32(®, TXRX_CSR0_DROP_MULTICAST,
!(filter_flags & FIF_ALLMULTI));
--
1.5.4.5
On Mon, 2008-03-31 at 15:24 +0200, Ivo van Doorn wrote:
> The TO_DS filter does not only depend on the FIF_PROMISC_IN_BSS flag
> provided by mac80211, but also on the intf_ap_count count.
> This makes sense, since when Master mode is active, we should all frames
> that are send to the active AP (the device itself).
>
> This means that when an interface is added we should force the
> packet filter to be updated during the next mac80211 call of
> configure_filter() to make sure the intf_ap_count field is checked.
I can confirm that this solves the problem that causes hostapd (running
on rt2500pci) to fail to receive EAPOL key frames from a client that
tries to connect. So you can scratch this one from your todo list,
Johannes.
many thanks, Ivo and Johannes!
unfortunately I still don't have a working AP, since hostapd crashes
when receiving the EAPOL key from the client. I'm still trying to find
out what exactly happens, I'll post more info in a new thread. I'm
inclined to think that the problem lies on the driver side, since this
used to work at the 31st of January this year, with hostapd-0.6.2, which
is the version I've tested with now.
best regards,
Bas Hulsken
On Tue, 2008-04-01 at 14:10 +0200, Johannes Berg wrote:
> > unfortunately I still don't have a working AP, since hostapd crashes
> > when receiving the EAPOL key from the client. I'm still trying to find
> > out what exactly happens, I'll post more info in a new thread. I'm
> > inclined to think that the problem lies on the driver side, since this
> > used to work at the 31st of January this year, with hostapd-0.6.2, which
> > is the version I've tested with now.
>
> What exactly happens? I guess you have my (single) hostapd patch
> applied?
I'm still not sure, I decided to investigate a bit more, before I bother
you with a stupid mistake on my side. I'm reasonably sure I applied your
hostapd patch (001-beacon-int-hack.patch, right?), but I'll check again
tonight, when I have direct access to the machine. Next to that, I've
also had to patch hostapd a bit further, else it wouldn't compile. I've
renamed all NL80211_STA_STAT_* to NL80211_STA_INFO_* in
driver_nl80211.c, see attached patch. Was that ok? It seemed trivial.
What seems to happen, is that wlan1 receives exactly one frame from the
laptop, and then hostapd hangs, and no further frames are sent from
hostapd, although beacon frames are still being sent, and the interface
still receives frames as well. This happens immediately after rt2500pci
receives the EAPOL key from the laptop, so I guess it is in fact the
EAPOL key that is the single frame that wlan1 receives. As I've
mentioned before, only ctrl-c can kill hostapd, and after that the
driver is in an unusable state (at least for hostapd) rmmod rt2500pci,
followed by insmod rt2500pci returns stuff to a usable state.
well, I'll look into it a bit more, I've attached the hostapd output
(hostapd.log), and a capture of all frames on rt2500pci (dump.pcap)
together with hostapd.conf and ifcfg-wlan1, perhaps you can see
something obvious.
thanks for your help,
Bas Hulsken
> unfortunately I still don't have a working AP, since hostapd crashes
> when receiving the EAPOL key from the client. I'm still trying to find
> out what exactly happens, I'll post more info in a new thread. I'm
> inclined to think that the problem lies on the driver side, since this
> used to work at the 31st of January this year, with hostapd-0.6.2, which
> is the version I've tested with now.
What exactly happens? I guess you have my (single) hostapd patch
applied?
johannes