[PATCH 08/10] mac80211: send last 3/5 probe requests as unicast

[PATCH 08/10] mac80211: send last 3/5 probe requests as unicast

[Luis R. Rodriguez]

Some buggy APs do not respond to unicast probe requests
or send unicast probe requests very delayed so in the
worst case we should try to send broadcast probe requests,
otherwise we can get disconnected from these APs.

Even if drivers do not have filters to disregard probe
responses from foreign APs mac80211 will only process
probe responses from our associated AP for re-arming
connection monitoring.

We need to do this since the beacon monitor does not
push back the connection monitor by design so even if we
are getting beacons from these type of APs our connection
monitor currently relies heavily on the way the probe
requests are received on the AP. An example of an AP
affected by this is the Nexus One, but this has also been
observed with random APs.

We can probably optimize this later by using null funcs
instead of probe requests.

For more details refer to:

http://code.google.com/p/chromium-os/issues/detail?id=5715

This patch has fixes for stable kernels [2.6.35+]

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/mac80211/mlme.c |   13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index c2e1838..816566b 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1038,10 +1038,19 @@ static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
 {
 	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
 	const u8 *ssid;
+	u8 *dst = ifmgd->associated->bssid;
+	u8 unicast_limit = max(1, IEEE80211_MAX_PROBE_TRIES - 3);
+
+	/*
+	 * Try sending broadcast probe requests for the last three
+	 * probe requests after the first ones failed since some
+	 * buggy APs only support broadcast probe requests.
+	 */
+	if (ifmgd->probe_send_count >= unicast_limit)
+		dst = NULL;
 
 	ssid = ieee80211_bss_get_ie(ifmgd->associated, WLAN_EID_SSID);
-	ieee80211_send_probe_req(sdata, ifmgd->associated->bssid,
-				 ssid + 2, ssid[1], NULL, 0);
+	ieee80211_send_probe_req(sdata, dst, ssid + 2, ssid[1], NULL, 0);
 
 	ifmgd->probe_send_count++;
 	ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
-- 
1.7.0.4

Re: [PATCH 08/10] mac80211: send last 3/5 probe requests as unicast

[Kalle Valo]

"Luis R. Rodriguez" <lrodriguez@atheros.com> writes:

> We need to do this since the beacon monitor does not
> push back the connection monitor by design so even if we
> are getting beacons from these type of APs our connection
> monitor currently relies heavily on the way the probe
> requests are received on the AP. An example of an AP
> affected by this is the Nexus One, but this has also been
> observed with random APs.
>
> We can probably optimize this later by using null funcs
> instead of probe requests.

Beginning of this year I sent patches to use null funcs. Unfortunately
I had to drop them due to time constraints.

Also a major power consumption imporovement from using null func
frames is that we don't have to trigger dynamic power save timer
during the poll. Just send the frame with PSM bit set, wait for ack
and go immeaditely back to sleep. So instead of having radios enabled
for example 100 ms per frame, we can do it in just 1 ms.

-- 
Kalle Valo

Re: [PATCH 08/10] mac80211: send last 3/5 probe requests as unicast

[Luis R. Rodriguez]

On Tue, Sep 14, 2010 at 3:12 PM, Kalle Valo <kvalo@adurom.com> wrote:
> "Luis R. Rodriguez" <lrodriguez@atheros.com> writes:
>
>> We need to do this since the beacon monitor does not
>> push back the connection monitor by design so even if we
>> are getting beacons from these type of APs our connection
>> monitor currently relies heavily on the way the probe
>> requests are received on the AP. An example of an AP
>> affected by this is the Nexus One, but this has also been
>> observed with random APs.
>>
>> We can probably optimize this later by using null funcs
>> instead of probe requests.
>
> Beginning of this year I sent patches to use null funcs. Unfortunately
> I had to drop them due to time constraints.
>
> Also a major power consumption imporovement from using null func
> frames is that we don't have to trigger dynamic power save timer
> during the poll. Just send the frame with PSM bit set, wait for ack
> and go immeaditely back to sleep. So instead of having radios enabled
> for example 100 ms per frame, we can do it in just 1 ms.

Neat, do you have those patches dug up in a directory somewhere or
should I dig the archives?

  Luis

Re: [PATCH 08/10] mac80211: send last 3/5 probe requests as unicast

[Kalle Valo]

"Luis R. Rodriguez" <lrodriguez@atheros.com> writes:

>> Beginning of this year I sent patches to use null funcs. Unfortunately
>> I had to drop them due to time constraints.
>>
>> Also a major power consumption imporovement from using null func
>> frames is that we don't have to trigger dynamic power save timer
>> during the poll. Just send the frame with PSM bit set, wait for ack
>> and go immeaditely back to sleep. So instead of having radios enabled
>> for example 100 ms per frame, we can do it in just 1 ms.
>
> Neat, do you have those patches dug up in a directory somewhere or
> should I dig the archives?

They are here:

http://marc.info/?l=linux-wireless&m=126644065026466&w=2

But I'm sure they don't apply anymore. You interested about patch 2:

http://marc.info/?l=linux-wireless&m=126644065926485&w=2

-- 
Kalle Valo