| Message ID | 1249056896.20593.3.camel@maxim-laptop (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Fri, 2009-07-31 at 19:14 +0300, Maxim Levitsky wrote: > >From 0bf5749f2878f9245b8fb1b64456386374205225 Mon Sep 17 00:00:00 2001 > From: Maxim Levitsky <maximlevitsky@gmail.com> > Date: Fri, 31 Jul 2009 18:54:12 +0300 > Subject: [PATCH] [MAC80211] Retry probe request few times > > Retry 5 times (chosen arbitary ), before assuming > that station is out of range. > > Fixes frequent disassociations while connected to weak, > and sometimes even strong access points. Looks good, thanks. Acked-by: Johannes Berg <johannes@sipsolutions.net> > Signed-off-by: Maxim Levitky <maximlevitsky@gmail.com> > --- > net/mac80211/ieee80211_i.h | 1 + > net/mac80211/mlme.c | 42 ++++++++++++++++++++++++++++++------------ > 2 files changed, 31 insertions(+), 12 deletions(-) > > diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h > index aec6853..bca7b60 100644 > --- a/net/mac80211/ieee80211_i.h > +++ b/net/mac80211/ieee80211_i.h > @@ -280,6 +280,7 @@ struct ieee80211_if_managed { > struct work_struct beacon_loss_work; > > unsigned long probe_timeout; > + int probe_send_count; > > struct mutex mtx; > struct ieee80211_bss *associated; > diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c > index ee83125..1d8640a 100644 > --- a/net/mac80211/mlme.c > +++ b/net/mac80211/mlme.c > @@ -31,6 +31,7 @@ > #define IEEE80211_AUTH_MAX_TRIES 3 > #define IEEE80211_ASSOC_TIMEOUT (HZ / 5) > #define IEEE80211_ASSOC_MAX_TRIES 3 > +#define IEEE80211_MAX_PROBE_TRIES 5 > > /* > * beacon loss detection timeout > @@ -1156,11 +1157,24 @@ void ieee80211_sta_rx_notify(struct ieee80211_sub_if_data *sdata, > round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME)); > } > > +static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata) > +{ > + struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; > + const u8 *ssid; > + > + ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID); > + ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid, > + ssid + 2, ssid[1], NULL, 0); > + > + ifmgd->probe_send_count++; > + ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT; > + run_again(ifmgd, ifmgd->probe_timeout); > +} > + > static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata, > bool beacon) > { > struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; > - const u8 *ssid; > bool already = false; > > if (!netif_running(sdata->dev)) > @@ -1203,18 +1217,12 @@ static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata, > if (already) > goto out; > > - ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT; > - > mutex_lock(&sdata->local->iflist_mtx); > ieee80211_recalc_ps(sdata->local, -1); > mutex_unlock(&sdata->local->iflist_mtx); > > - ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID); > - ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid, > - ssid + 2, ssid[1], NULL, 0); > - > - run_again(ifmgd, ifmgd->probe_timeout); > - > + ifmgd->probe_send_count = 0; > + ieee80211_mgd_probe_ap_send(sdata); > out: > mutex_unlock(&ifmgd->mtx); > } > @@ -2072,17 +2080,27 @@ static void ieee80211_sta_work(struct work_struct *work) > if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL | > IEEE80211_STA_CONNECTION_POLL) && > ifmgd->associated) { > + u8 bssid[ETH_ALEN]; > + > + memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN); > if (time_is_after_jiffies(ifmgd->probe_timeout)) > run_again(ifmgd, ifmgd->probe_timeout); > - else { > - u8 bssid[ETH_ALEN]; > + > + else if (ifmgd->probe_send_count < IEEE80211_MAX_PROBE_TRIES) { > +#ifdef CONFIG_MAC80211_VERBOSE_DEBUG > + printk(KERN_DEBUG "No probe response from AP %pM" > + " after %dms, try %d\n", bssid, > + (1000 * IEEE80211_PROBE_WAIT)/HZ, > + ifmgd->probe_send_count); > +#endif > + ieee80211_mgd_probe_ap_send(sdata); > + } else { > /* > * We actually lost the connection ... or did we? > * Let's make sure! > */ > ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL | > IEEE80211_STA_BEACON_POLL); > - memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN); > printk(KERN_DEBUG "No probe response from AP %pM" > " after %dms, disconnecting.\n", > bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);
Hi Maxim, > From: Maxim Levitsky <maximlevitsky@gmail.com> > Date: Fri, 31 Jul 2009 18:54:12 +0300 > Subject: [PATCH] [MAC80211] Retry probe request few times > > Retry 5 times (chosen arbitary ), before assuming > that station is out of range. so today I got the disconnect :( [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2 [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2 [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3 [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4 [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting. Should we increase the value to 8 or something? Or just accept that sometimes we get a disconnect? Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2009-08-04 at 19:22 -0700, Marcel Holtmann wrote: > Hi Maxim, > > > From: Maxim Levitsky <maximlevitsky@gmail.com> > > Date: Fri, 31 Jul 2009 18:54:12 +0300 > > Subject: [PATCH] [MAC80211] Retry probe request few times > > > > Retry 5 times (chosen arbitary ), before assuming > > that station is out of range. > > so today I got the disconnect :( > > [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 > [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2 > [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 > [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 > [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2 > [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3 > [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4 > [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting. > > Should we increase the value to 8 or something? Or just accept that > sometimes we get a disconnect? > I think a disconnect or two aren't a problem, they are always handled automatically, and can be caused by natural events. Even without these patches (I have WPA2, and disconnects were every 4 five seconds), and still it was possible to use network. One disconnect in a day is really nothing to worry about (I have seen such here as well) You can increase try count, probably won't hurt much (each try is 0.5 seconds, so even 10 tries gives total of 5 seconds, before disconnect on a really unaccessible AP, anyway) Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2009-08-05 at 08:29 +0300, Maxim Levitsky wrote: > > [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 > > [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2 > > [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 > > [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 > > [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2 > > [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3 > > [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4 > > [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting. > > > > Should we increase the value to 8 or something? Or just accept that > > sometimes we get a disconnect? > > > I think a disconnect or two aren't a problem, they are always handled > automatically, and can be caused by natural events. > > Even without these patches (I have WPA2, and disconnects were every 4 > five seconds), and still it was possible to use network. > > One disconnect in a day is really nothing to worry about (I have seen > such here as well) > > You can increase try count, probably won't hurt much (each try is 0.5 > seconds, so even 10 tries gives total of 5 seconds, before disconnect on > a really unaccessible AP, anyway) Mind you, each try will end up sending a LOT of probe request frames, iwlwifi sends like 12 frames for every try and never gets a response for some reason, so I wouldn't really increase it much further since you'd be spamming around a lot. johannes
On Wed, Aug 5, 2009 at 7:33 AM, Johannes Berg<johannes@sipsolutions.net> wrote: > On Wed, 2009-08-05 at 08:29 +0300, Maxim Levitsky wrote: > >> > [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 >> > [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2 >> > [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 >> > [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 >> > [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2 >> > [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3 >> > [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4 >> > [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting. >> > >> > Should we increase the value to 8 or something? Or just accept that >> > sometimes we get a disconnect? >> > >> I think a disconnect or two aren't a problem, they are always handled >> automatically, and can be caused by natural events. >> >> Even without these patches (I have WPA2, and disconnects were every 4 >> five seconds), and still it was possible to use network. >> >> One disconnect in a day is really nothing to worry about (I have seen >> such here as well) >> >> You can increase try count, probably won't hurt much (each try is 0.5 >> seconds, so even 10 tries gives total of 5 seconds, before disconnect on >> a really unaccessible AP, anyway) > > Mind you, each try will end up sending a LOT of probe request frames, > iwlwifi sends like 12 frames for every try and never gets a response for > some reason, so I wouldn't really increase it much further since you'd > be spamming around a lot. > > johannes > My €0.02 (€ because I'm European :) ): Shouldn't probe requests be NO_ACK?
On Wed, 2009-08-05 at 07:50 +0200, Gábor Stefanik wrote:
> My €0.02 (€ because I'm European :) ): Shouldn't probe requests be NO_ACK?
Of course not. What makes you think so?
johannes
2009/8/5 Johannes Berg <johannes@sipsolutions.net>: > On Wed, 2009-08-05 at 07:50 +0200, Gábor Stefanik wrote: > >> My €0.02 (€ because I'm European :) ): Shouldn't probe requests be NO_ACK? > > Of course not. What makes you think so? > > johannes > > It just feels illogical to me that the AP essentially has to respond to probes twice (it sends an ACK, then a probe response) - but if that is what the 802.11 spec calls for, then its fine.
On Wed, 2009-08-05 at 07:53 +0200, Gábor Stefanik wrote: > It just feels illogical to me that the AP essentially has to respond > to probes twice (it sends an ACK, then a probe response) - but if that > is what the 802.11 spec calls for, then its fine. You're just confused then. Think about it again, it's perfectly logical. johannes
Hi Maxim, > > > From: Maxim Levitsky <maximlevitsky@gmail.com> > > > Date: Fri, 31 Jul 2009 18:54:12 +0300 > > > Subject: [PATCH] [MAC80211] Retry probe request few times > > > > > > Retry 5 times (chosen arbitary ), before assuming > > > that station is out of range. > > > > so today I got the disconnect :( > > > > [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 > > [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2 > > [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 > > [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1 > > [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2 > > [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3 > > [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4 > > [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting. > > > > Should we increase the value to 8 or something? Or just accept that > > sometimes we get a disconnect? > > > I think a disconnect or two aren't a problem, they are always handled > automatically, and can be caused by natural events. > > Even without these patches (I have WPA2, and disconnects were every 4 > five seconds), and still it was possible to use network. this assumption only works if you are not using NetworkManager or alike where every new connect triggers DHCP again. If we wanna survive them, then we have to teach them to handle the lease time more intelligent which is kinda tricky. Might be worth doing anyway. I have to play with it a little bit. > One disconnect in a day is really nothing to worry about (I have seen > such here as well) > > You can increase try count, probably won't hurt much (each try is 0.5 > seconds, so even 10 tries gives total of 5 seconds, before disconnect on > a really unaccessible AP, anyway) Or just increase the try to 1 second. I still think there is something odd going on with the iwlwifi driver here, but so far nobody saw anything that is obviously wrong. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h index aec6853..bca7b60 100644 --- a/net/mac80211/ieee80211_i.h +++ b/net/mac80211/ieee80211_i.h @@ -280,6 +280,7 @@ struct ieee80211_if_managed { struct work_struct beacon_loss_work; unsigned long probe_timeout; + int probe_send_count; struct mutex mtx; struct ieee80211_bss *associated; diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index ee83125..1d8640a 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -31,6 +31,7 @@ #define IEEE80211_AUTH_MAX_TRIES 3 #define IEEE80211_ASSOC_TIMEOUT (HZ / 5) #define IEEE80211_ASSOC_MAX_TRIES 3 +#define IEEE80211_MAX_PROBE_TRIES 5 /* * beacon loss detection timeout @@ -1156,11 +1157,24 @@ void ieee80211_sta_rx_notify(struct ieee80211_sub_if_data *sdata, round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME)); } +static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata) +{ + struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; + const u8 *ssid; + + ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID); + ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid, + ssid + 2, ssid[1], NULL, 0); + + ifmgd->probe_send_count++; + ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT; + run_again(ifmgd, ifmgd->probe_timeout); +} + static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata, bool beacon) { struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; - const u8 *ssid; bool already = false; if (!netif_running(sdata->dev)) @@ -1203,18 +1217,12 @@ static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata, if (already) goto out; - ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT; - mutex_lock(&sdata->local->iflist_mtx); ieee80211_recalc_ps(sdata->local, -1); mutex_unlock(&sdata->local->iflist_mtx); - ssid = ieee80211_bss_get_ie(&ifmgd->associated->cbss, WLAN_EID_SSID); - ieee80211_send_probe_req(sdata, ifmgd->associated->cbss.bssid, - ssid + 2, ssid[1], NULL, 0); - - run_again(ifmgd, ifmgd->probe_timeout); - + ifmgd->probe_send_count = 0; + ieee80211_mgd_probe_ap_send(sdata); out: mutex_unlock(&ifmgd->mtx); } @@ -2072,17 +2080,27 @@ static void ieee80211_sta_work(struct work_struct *work) if (ifmgd->flags & (IEEE80211_STA_BEACON_POLL | IEEE80211_STA_CONNECTION_POLL) && ifmgd->associated) { + u8 bssid[ETH_ALEN]; + + memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN); if (time_is_after_jiffies(ifmgd->probe_timeout)) run_again(ifmgd, ifmgd->probe_timeout); - else { - u8 bssid[ETH_ALEN]; + + else if (ifmgd->probe_send_count < IEEE80211_MAX_PROBE_TRIES) { +#ifdef CONFIG_MAC80211_VERBOSE_DEBUG + printk(KERN_DEBUG "No probe response from AP %pM" + " after %dms, try %d\n", bssid, + (1000 * IEEE80211_PROBE_WAIT)/HZ, + ifmgd->probe_send_count); +#endif + ieee80211_mgd_probe_ap_send(sdata); + } else { /* * We actually lost the connection ... or did we? * Let's make sure! */ ifmgd->flags &= ~(IEEE80211_STA_CONNECTION_POLL | IEEE80211_STA_BEACON_POLL); - memcpy(bssid, ifmgd->associated->cbss.bssid, ETH_ALEN); printk(KERN_DEBUG "No probe response from AP %pM" " after %dms, disconnecting.\n", bssid, (1000 * IEEE80211_PROBE_WAIT)/HZ);