allow AP interfaces to handle BACK action frames
PATCH 1/1 allow AP interfaces to handle BACK action frames
Add AP mode to the allowed interface check in ieee80211_rx_h_action. This function handles BACK action frames such as ADDBA and AP interfaces need to receive those.
net/mac80211/rx.c +2 -1
@@ -1553,7 +1553,8 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)* of these frames in other modes as well! */ if (sdata->vif.type !=NL80211_IFTYPE_STATION && - sdata->vif.type !=NL80211_IFTYPE_ADHOC ) + sdata->vif.type !=NL80211_IFTYPE_ADHOC && + sdata->vif.type !=NL80211_IFTYPE_AP )return RX_CONTINUE ;switch (mgmt->u.action.category) {
Quoted 3 lines · Andrey Yurovsky
Add AP mode to the allowed interface check in
ieee80211_rx_h_action. This function handles BACK action frames such as ADDBA and AP interfaces need to receive those.
You forgot mac80211 from the subject, it should be something like this:
[PATCH] mac80211: allow AP interfaces to handle BACK action frames
Signature · 1 line
Kalle Valo
Johannes Berg
maintainerQuoted 5 lines · Andrey Yurovsky
Add AP mode to the allowed interface check in
ieee80211_rx_h_action. This function handles BACK action frames such as ADDBA and AP interfaces need to receive those.Signed-off-by Andrey Yurovsky <[email protected]>
Fine with me, but I think you need to allow VLAN too? Also, how about simply removing this check? Can anything bad happen when we try this in an IBSS or on WDS or on MESH?
johannes
Quoted 21 lines
net/mac80211/rx.c +2
-2@@ -1553,7 +1553,8 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)* of these frames in other modes as well! */ if (sdata->vif.type !=NL80211_IFTYPE_STATION && - sdata->vif.type !=NL80211_IFTYPE_ADHOC ) + sdata->vif.type !=NL80211_IFTYPE_ADHOC && + sdata->vif.type !=NL80211_IFTYPE_AP )return RX_CONTINUE ;switch (mgmt->u.action.category) { --To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
As I understand it, despite the "h" in ieee80211_rx_h_action, it filters both BACK (802.11e and required for 802.11n) and spectrum management (802.11h) action frames. I suppose that the entire check isn't really necessary. I don't know much about the WLAN_ACTION_SPCT_MSR_REQ frame but as far as the BACK frames, there shouldn't be any harm with passing them to the driver for any of the interface types. Should I resubmit this as removing the check entirely? Should there perhaps be separate functions for the 11e and 11h action frames?
Additionally, with the check the way it currently is, an AP interface (for example) will respond to an ADDBA frame with something strange (action code 0x83 for starters, and the rest of the action frame doesn't make sense), at least with iwlagn. It seems that if the check fails and we don't pass the frame to the driver, something weird still happens (otherwise, for iwlagn at least, the right thing happens). I haven't had a chance to see if other drivers / interfaces do that.
Thanks,
Quoted 35 lines · Johannes Berg
Quoted 5 lines · Andrey Yurovsky
Add AP mode to the allowed interface check in
ieee80211_rx_h_action. This function handles BACK action frames such as ADDBA and AP interfaces need to receive those.Signed-off-by Andrey Yurovsky <[email protected]>Fine with me, but I think you need to allow VLAN too? Also, how about simply removing this check? Can anything bad happen when we try this in an IBSS or on WDS or on MESH?
johannes
Quoted 21 lines
net/mac80211/rx.c +2
-2@@ -1553,7 +1553,8 @@ ieee80211_rx_h_action(struct ieee80211_rx_data *rx)* of these frames in other modes as well! */ if (sdata->vif.type !=NL80211_IFTYPE_STATION && - sdata->vif.type !=NL80211_IFTYPE_ADHOC ) + sdata->vif.type !=NL80211_IFTYPE_ADHOC && + sdata->vif.type !=NL80211_IFTYPE_AP )return RX_CONTINUE ;switch (mgmt->u.action.category) { --To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
oops, I meant "don't call a handler for the frame", not "don't pass the frame to the driver", sorry.
Johannes Berg
maintainerQuoted 1 line · Andrey Yurovsky
As I understand it, despite the "h" in
ieee80211_rx_h_action,
Heh. That is part of _rx_h which stands for RX handler :)
Quoted 8 lines
it
filters both BACK (802.11e and required for 802.11n) and spectrum management (802.11h) action frames. I suppose that the entire check isn't really necessary. I don't know much about theWLAN_ACTION_SPCT_MSR_REQframe but as far as the BACK frames, there shouldn't be any harm with passing them to the driver for any of the interface types. Should I resubmit this as removing the check entirely?
I think so.
Quoted 2 lines
Should there perhaps be separate functions for the 11e and
11h action frames?
Possible, although right now we only handle measurement requests by rejecting them...
Quoted 7 lines
Additionally, with the check the way it currently is, an AP interface (for example) will respond to an ADDBA frame with something strange (action code
0x83for starters, and the rest of the action frame doesn't make sense), at least with iwlagn. It seems that if the check fails and we don't pass the frame to the driver, something weird still happens (otherwise, for iwlagn at least, the right thing happens). I haven't had a chance to see if other drivers / interfaces do that.
Do we know where that frame comes from?
johannes