I'm trying to get userspace client MLME working again and the next
blocker seems to be in Probe Response frames being dropped during
scanning (prepare_for_handlers() rejects frame due to BSSID mismatch
when "not in scan" (which is currently defined as kernel MLME or hw
scan).
I can workaround this with the patch below, but I would assume there are
some consequences in doing this (at least as far as CPU use is
concerned). Would there be a better way of doing this? Should I add yet
another parameter (like sdata->flags IEEE80211_SDATA_USERSPACE_MLME) for
indicating another type of scan (userspace MLME scanning) and get
wpa_supplicant setting that around scan operations? That would get
rx->flags IEEE80211_RX_IN_SCAN set in __ieee80211_rx_handle_packet and
consequently, would likely allow the ProbeResp frames to be received in
this case.
Any preferences or comments on this?
Index: wireless-testing/net/mac80211/rx.c
===================================================================
--- wireless-testing.orig/net/mac80211/rx.c
+++ wireless-testing/net/mac80211/rx.c
@@ -1828,7 +1828,8 @@ static int prepare_for_handlers(struct i
if (!bssid)
return 0;
if (!ieee80211_bssid_match(bssid, sdata->u.sta.bssid)) {
- if (!(rx->flags & IEEE80211_RX_IN_SCAN))
+ if (!(rx->flags & IEEE80211_RX_IN_SCAN) &&
+ !(sdata->flags & IEEE80211_SDATA_USERSPACE_MLME))
return 0;
rx->flags &= ~IEEE80211_RX_RA_MATCH;
} else if (!multicast &&
--
Jouni Malinen PGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
