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:
wpa_eap.log.gz
Description: GNU Zip compressed data
