aboutsummaryrefslogtreecommitdiff
path: root/net/mac80211
diff options
context:
space:
mode:
authorJouni Malinen <jouni.malinen@atheros.com>2009-05-14 21:15:36 +0300
committerJohn W. Linville <linville@tuxdriver.com>2009-05-20 14:46:24 -0400
commit92778180f7fca7f7797de8020900a7fea175f7e3 (patch)
treed65b23ececcd2fab32b1b372f7ad1c629fde5986 /net/mac80211
parent13bdcd90bbce7c07e0dda0ff31e9497b8cabf1eb (diff)
mac80211: Cancel pending probereq poll on beacon RX
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@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'net/mac80211')
-rw-r--r--net/mac80211/mlme.c10
1 files changed, 10 insertions, 0 deletions
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index a1944b8722e..47bc3030ca8 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1824,6 +1824,16 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
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,