summaryrefslogtreecommitdiffstats
path: root/net/mac80211
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2012-07-18 10:27:27 +0200
committerJohannes Berg <johannes.berg@intel.com>2012-07-31 16:10:58 +0200
commit7eeff74c29259e9cb7765e3845c0b74057f744da (patch)
treecfb18a70ebf04ad24856eb5578296abbcb1b2bb4 /net/mac80211
parentd545daba5357c1ca377a4fe917ccf4de3a3031e0 (diff)
downloadlinux-7eeff74c29259e9cb7765e3845c0b74057f744da.tar.gz
linux-7eeff74c29259e9cb7765e3845c0b74057f744da.tar.bz2
linux-7eeff74c29259e9cb7765e3845c0b74057f744da.zip
mac80211: don't react to beacon loss if HW monitoring
If the HW is monitoring connection loss (as advertised by IEEE80211_HW_CONNECTION_MONITOR) but not filtering beacons (IEEE80211_VIF_BEACON_FILTER) then mac80211 will still start the beacon loss timer and if a few beacons are lost, e.g. due to scanning, drop the connection. If the hardware doesn't advertise connection monitoring, then it won't drop the connection right away but probe the AP, which is intended, but due to the logic in the timer when connection monitoring is done it assumes the connection was actually lost. Fix this problem by not starting the timer when the HW does connection monitoring. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'net/mac80211')
-rw-r--r--net/mac80211/mlme.c3
1 files changed, 3 insertions, 0 deletions
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 725258c20746..81b2269e8f3a 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -146,6 +146,9 @@ void ieee80211_sta_reset_beacon_monitor(struct ieee80211_sub_if_data *sdata)
if (sdata->vif.driver_flags & IEEE80211_VIF_BEACON_FILTER)
return;
+ if (sdata->local->hw.flags & IEEE80211_HW_CONNECTION_MONITOR)
+ return;
+
mod_timer(&sdata->u.mgd.bcn_mon_timer,
round_jiffies_up(jiffies + sdata->u.mgd.beacon_timeout));
}