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]>
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 080b0ce..fe406f5 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -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) {
oops, I meant "don't call a handler for the frame", not "don't pass
the frame to the driver", sorry.
Andrey Yurovsky <[email protected]> writes:
> 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
--
Kalle Valo
On Wed, 2008-10-08 at 16:18 -0700, Andrey Yurovsky wrote:
> 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
> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> index 080b0ce..fe406f5 100644
> --- a/net/mac80211/rx.c
> +++ b/net/mac80211/rx.c
> @@ -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
>
On Thu, 2008-10-09 at 10:38 -0700, Andrey Yurovsky wrote:
> As I understand it, despite the "h" in ieee80211_rx_h_action,
Heh. That is part of _rx_h which stands for RX handler :)
> 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?
I think so.
> 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...
> 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.
Do we know where that frame comes from?
johannes
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,
On Thu, Oct 9, 2008 at 2:56 AM, Johannes Berg <[email protected]> wrote:
> On Wed, 2008-10-08 at 16:18 -0700, Andrey Yurovsky wrote:
>> 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
>
>> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
>> index 080b0ce..fe406f5 100644
>> --- a/net/mac80211/rx.c
>> +++ b/net/mac80211/rx.c
>> @@ -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
>>
>