mac80211: Restore rx.fc before every invocation of ieee80211_invoke_rx_handlers
PATCH 1/1 mac80211: Restore rx.fc before every invocation of ieee80211_invoke_rx_handlers
This patch fixes a problem with rx handling on multiple interfaces. Especially when using hardware-scanning and a wireless driver (i.e. iwlwifi) which is able to receive data while scanning.
The rx handlers can modify the skb and the frame control field (see ieee80211_rx_h_remove_qos_control) but since every interface gets its own copy of the skb each should get its own copy of rx.fc too.
In my case the wlan0-interface did not remove the qos-control from the frame because the corresponding flag in rx.fc was already removed while processing the frame on the master interface. Therefore somehow corrupted frames were passed to the userspace.
---
net/mac80211/rx.c +0 -0
@@ -1723,6 +1723,7 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct
sk_buff *skb,
prev->dev->name);
continue;
}
+ rx.fc = le16_to_cpu(hdr->frame_control);
rx.skb = skb_new;
rx.dev = prev->dev;
rx.sdata = prev;
@@ -1731,6 +1732,7 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb,
prev = sdata;
}
if (prev) {
+ rx.fc = le16_to_cpu(hdr->frame_control);
rx.skb = skb;
rx.dev = prev->dev;
rx.sdata = prev;
Johannes Berg
maintainerQuoted 3 lines · Helmut Schaa
This patch fixes a problem with rx handling on multiple interfaces. Especially when using hardware-scanning and a wireless driver (i.e. iwlwifi) which is able to receive data while scanning.
Can you explain how you even got multiple interfaces with iwlwifi? The patch looks (superficially) correct, but I'm a bit confused.
johannes
Am So 23 Dez 2007 10:24:39 CET schrieb Johannes Berg <[email protected]>:
Quoted 9 lines · Helmut Schaa
Quoted 4 lines
This patch fixes a problem with rx handling on multiple interfaces.
Especially
when using hardware-scanning and a wireless driver (i.e. iwlwifi) which is able to receive data while scanning.Can you explain how you even got multiple interfaces with iwlwifi? The patch looks (superficially) correct, but I'm a bit confused.
I was only referring to wmaster0 and wlan0 as two interfaces. While a scan is in progress the master interface (wmaster0) processes all frames related to scanning and it happened to me that data-frames got dropped on wmaster0 (which is obviously correct) and due to the frame control being modified wlan0 was not able to process the frame correctly anymore.
Helmut
Johannes Berg
maintainerQuoted 6 lines
Quoted 6 lines
Quoted 5 lines
This patch fixes a problem with rx handling on multiple interfaces.
Especially
when using hardware-scanning and a wireless driver (i.e. iwlwifi) which is able to receive data while scanning.
Quoted 8 lines
Quoted 2 lines
Can you explain how you even got multiple interfaces with iwlwifi? The patch looks (superficially) correct, but I'm a bit confused.
I was only referring to wmaster0 and wlan0 as two interfaces. While a scan is in progress the master interface (wmaster0) processes all frames related to scanning and it happened to me that data-frames got dropped on wmaster0 (which is obviously correct) and due to the frame control being modified wlan0 was not able to process the frame correctly anymore.
Ah, that must be because of the stuff Zhu Yi did wrt. hw scanning. Could you take a look too please? The patch looks pretty much ok to me and I think it'd be required with say VLAN interfaces as well.
johannes
Am So 23 Dez 2007 14:48:26 CET schrieb Johannes Berg <[email protected]>:
Quoted 10 lines
Quoted 10 lines
Quoted 4 lines
Quoted 4 lines
This patch fixes a problem with rx handling on multiple interfaces.
Especially
when using hardware-scanning and a wireless driver (i.e.iwlwifi) which is
Quoted 4 lines
Quoted 1 line
able to receive data while scanning.
Can you explain how you even got multiple interfaces with iwlwifi? The patch looks (superficially) correct, but I'm a bit confused.
Quoted 7 lines
Quoted 5 lines
I was only referring to wmaster0 and wlan0 as two interfaces. While a scan is in progress the master interface (wmaster0) processes all frames related to scanning and it happened to me that data-frames got dropped on wmaster0 (which is obviously correct) and due to the frame control being modified wlan0 was not able to process the frame correctly anymore.
Ah, that must be because of the stuff Zhu Yi did wrt. hw scanning. Could
Exactly.
Quoted 2 lines
you take a look too please? The patch looks pretty much ok to me and I think it'd be required with say VLAN interfaces as well.
The patch looks fine to me too and with the additional patch I was able to receive data while a scan is in progress (hw_scan only of course).
Helmut
Quoted 3 lines · Johannes Berg
Ah, that must be because of the stuff Zhu Yi did wrt. hw scanning. Could you take a look too please? The patch looks pretty much ok to me and I think it'd be required with say VLAN interfaces as well.
The patch looks fine to me. Hardware scanning is a trigger that makes the condition more likely to happen, the patch itself fixes the more general problem for multiple interfaces.
An off-topic question: should wmaster0 continue to execute more rx handlers (i.e ieee80211_rx_h_remove_qos_control) even if it knows it will drop them finially?
Thanks,
-yi
Johannes Berg
maintainerQuoted 4 lines
The patch looks fine to me. Hardware scanning is a trigger that makes the condition more likely to happen, the patch itself fixes the more general problem for multiple interfaces.
Yeah, I think so too.
Quoted 3 lines
An off-topic question: should wmaster0 continue to execute more rx handlers (i.e
ieee80211_rx_h_remove_qos_control) even if it knows it will drop them finially?
I don't think it does, does it? In prepare_for_handlers frames aren't sent to the master device while not scanning.
johannes
Am Mo 24 Dez 2007 11:23:51 CET schrieb Johannes Berg <[email protected]>:
Quoted 5 lines
Quoted 4 lines
The patch looks fine to me. Hardware scanning is a trigger that makes the condition more likely to happen, the patch itself fixes the more general problem for multiple interfaces.
Quoted 8 lines
Yeah, I think so too.
Quoted 3 lines
An off-topic question: should wmaster0 continue to execute more rx handlers (i.e
ieee80211_rx_h_remove_qos_control) even if it knows it will drop them finially?I don't think it does, does it? In
prepare_for_handlersframes aren't sent to the master device while not scanning.
It does so only during a scan. In that case the frame gets first dropped in ieee80211_rx_h_data on the master device.
Helmut
Quoted 2 lines · Johannes Berg
I don't think it does, does it? In
prepare_for_handlersframes aren't sent to the master device while not scanning.
Should we also discard frames to mdev if ((rx->fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA)?
Thanks,
-yi
Johannes Berg
maintainerQuoted 6 lines · Zhu Yi
Quoted 2 lines · Johannes Berg
I don't think it does, does it? In
prepare_for_handlersframes aren't sent to the master device while not scanning.Should we also discard frames to mdev if ((
rx->fc&IEEE80211_FCTL_FTYPE) ==IEEE80211_FTYPE_DATA)?
I guess we should, yeah. In fact, I'd like to make the scan code short-cut and not go through the master device so we can completely remove RX on the master.
johannes