While the probe request poll is expected to work, it looks like it
does not always result in getting a response. The exact reason for
this is unclear, but anyway, if we do receive a Beacon frame from our
AP, there is no need to disconnect based on the probereq poll. This
seems to help keep the connection bit more stable in cases where
beacon loss is occurring semi-frequently.
Signed-off-by: Jouni Malinen <jouni.malinen@xxxxxxxxxxx>
---
net/mac80211/mlme.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- wireless-testing.orig/net/mac80211/mlme.c 2009-05-14 21:12:52.000000000 +0300
+++ wireless-testing/net/mac80211/mlme.c 2009-05-14 21:13:08.000000000 +0300
@@ -1820,6 +1820,16 @@ static void ieee80211_rx_mgmt_beacon(str
memcmp(ifmgd->bssid, mgmt->bssid, ETH_ALEN) != 0)
return;
+ if (ifmgd->flags & IEEE80211_STA_PROBEREQ_POLL) {
+#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
+ if (net_ratelimit()) {
+ printk(KERN_DEBUG "%s: cancelling probereq poll due "
+ "to a received beacon\n", sdata->dev->name);
+ }
+#endif
+ ifmgd->flags &= ~IEEE80211_STA_PROBEREQ_POLL;
+ }
+
ncrc = crc32_be(0, (void *)&mgmt->u.beacon.beacon_int, 4);
ncrc = ieee802_11_parse_elems_crc(mgmt->u.beacon.variable,
len - baselen, &elems,
--
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
