Due to the use of a _REQ_DIRECT_PROBE bit, which is
unnecessary (and I wonder why it was done that way),
an interesting situation can arise:
1) we try to probe an access point
2) the AP doesn't response in time
3) we tell userspace that we gave up
4) the AP suddenly responds
5) we auth/assoc with the AP
I've seen 4) happen in testing with hostapd SIGSTOPped,
and when SIGCONTinued it processes the probe requests
that came in and send responses. But 5) is not supposed
to happen after we tell everybody we've given up on the
AP.
To fix this, remove the _REQ_DIRECT_PROBE request bit,
and process probe responses when we're in the relevant
MLME state, namely IEEE80211_STA_MLME_DIRECT_PROBE.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
#define IEEE80211_STA_EXT_SME BIT(17)
/* flags for MLME request */
#define IEEE80211_STA_REQ_SCAN 0
-#define IEEE80211_STA_REQ_DIRECT_PROBE 1
-#define IEEE80211_STA_REQ_AUTH 2
-#define IEEE80211_STA_REQ_RUN 3
+#define IEEE80211_STA_REQ_AUTH 1
+#define IEEE80211_STA_REQ_RUN 2
/* bitfield of allowed auth algs */
#define IEEE80211_AUTH_ALG_OPEN BIT(0)
ifmgd->state = IEEE80211_STA_MLME_DIRECT_PROBE;
- set_bit(IEEE80211_STA_REQ_DIRECT_PROBE, &ifmgd->request);
-
/* Direct probe is sent to broadcast address as some APs
* will not answer to direct packet in unassociated state.
*/
ieee80211_rx_bss_info(sdata, mgmt, len, rx_status, &elems, false);
/* direct probe may be part of the association flow */
- if (test_and_clear_bit(IEEE80211_STA_REQ_DIRECT_PROBE,
- &ifmgd->request)) {
+ if (ifmgd->state == IEEE80211_STA_MLME_DIRECT_PROBE) {
printk(KERN_DEBUG "%s direct probe responded\n",
sdata->dev->name);
ieee80211_authenticate(sdata);