Re: Linux Client vs. CISCO AP with band select

[Wolfgang Breyha <wbreyha@gmx.net>]

[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]

Hi!

On 2010-11-20 13:04, Helmut Schaa wrote:
> If the Cisco APs would reply to direct probes we could (as a workaround) just
> send an additional direct probe here. I agree with Jouni that the AP behavior
> is just stupid but the users will blame Linux for not being able to connect
> and not the AP vendor.
> 
> Wolfgang, could you please try the (untested) patch below if it makes any
> difference?

Sorry, it took me a day longer as promised because I had to stay at home
yesterday.

The patch from Helmut didn't change anything. I even tried to send both
broadcast and direct probes in triples to check if that's the threshold
which is configured in band select as retries. It's not;-)

After that I tried a dirty hack on wpa_supplicant 0.7.3:
-------
--- wpa_supplicant-0.7.3.orig/wpa_supplicant/sme.c	2010-09-07
17:43:39.000000000 +0200
+++ wpa_supplicant-0.7.3/wpa_supplicant/sme.c	2010-11-23
15:21:23.866829986 +0100
@@ -456,8 +456,23 @@
 void sme_event_auth_timed_out(struct wpa_supplicant *wpa_s,
 			      union wpa_event_data *data)
 {
+	int timeout = 5000;
 	wpa_printf(MSG_DEBUG, "SME: Authentication timed out");
-	wpa_supplicant_req_scan(wpa_s, 5, 0);
+	if (wpa_blacklist_add(wpa_s, wpa_s->pending_bssid) == 0) {
+		struct wpa_blacklist *b;
+		wpa_blacklist_add(wpa_s, wpa_s->pending_bssid);
+		b = wpa_blacklist_get(wpa_s, wpa_s->pending_bssid);
+		if (b && b->count < 3) {
+			/*
+			 * Speed up next attempt if there could be other APs
+			 * that could accept association.
+			 */
+			timeout = 100;
+		}
+	}
+	wpa_supplicant_req_scan(wpa_s, timeout / 1000,
+				1000 * (timeout % 1000));
+//	wpa_supplicant_req_scan(wpa_s, 5, 0);
 }


--------
In other words I reused the code found in sme_event_assoc_reject() to
add the BSSID to the blacklist. To speed up things further I add it
twice;-) I don't know why wpa_supplicant needs a blacklist count of 2 to
finally try an other BSSID.

And it helps a lot. With this change wpa_supplicant stops retrying the
same BSSID all the time and tries a 5GHz one pretty fast. And I think
that's exactly what CISCO tries to achieve.

Finally there is another timeout in the EAP stage (SUPP_BE) I can't
pinpoint. I attached the wpa_supplicant.log.

Authenticated once reauthentication works very fast if needed.

Knowing where to search and how to hack mac80211 and wpa_supplicant I'll
try to find some details which probes CISCO responds to reaching the
threshold.

I can still provide packet traces if you need/want them. In case of the
load balancing feature it may take some time because I've not found a
trick to provoke it. But I think a well and fast trained blacklist will
help in this case, too.

Greetings,
Wolfgang

[-- Attachment #2: wpa_eap.log.gz --]
[-- Type: application/x-gzip, Size: 3196 bytes --]