I had gotten that, but the issue is that this particular syslog excerpt has so many things happening in it it's hard to figure out what's wrong from what's okay: for instance, at some point wpasupplicant gets killed with signal 15, and there's at least one instance of either a suspend/resume cycle or a case where networking/wifi was disabled then re-enabled. It muddies the waters a little.
I think I may have gotten to some good info; but it's nothing that clearly points towards a wpasupplicant issue. There's two cases here: 1) You'll pretty often roam from a BSS to another due to differring signal levels. I think we *may* want to consider whether roaming for this little difference is really worth it (didn't really check the code to see what kind of threshold is set). Oct 11 17:51:44 panhandle wpa_supplicant[772]: Considering within-ESS reassociation Oct 11 17:51:44 panhandle wpa_supplicant[772]: Current BSS: 00:0b:86:d5:1e:91 level=175 Oct 11 17:51:44 panhandle wpa_supplicant[772]: Selected BSS: 00:0b:86:d5:16:51 level=177 Oct 11 17:51:44 panhandle wpa_supplicant[772]: Trying to associate with 00:0b:86:d5:16:51 (SSID='wpa.mcgill.ca' freq=5745 MHz) That's part of why you shortly after that see a "deauth by local choice (reason=3)": reason 3 is WLAN_REASON_DEAUTH_LEAVING; due to roaming or any such cases. 2) Not all wpa.mcgill.ca APs seem to properly respond to the auth requests; seemingly due to overloading. Consider the following instance: Oct 11 17:47:58 panhandle kernel: [55574.563224] wlan0: authenticate with 00:0b:86:d5:16:41 (try 1) Oct 11 17:47:58 panhandle kernel: [55574.566014] wlan0: 00:0b:86:d5:16:41 denied authentication (status 17) Oct 11 17:48:02 panhandle NetworkManager[568]: <warn> Activation (wlan0/wireless): association took too long. Oct 11 17:48:02 panhandle NetworkManager[568]: <info> (wlan0): device state change: 5 -> 6 (reason 0) Oct 11 17:48:02 panhandle wpa_supplicant[772]: dbus: Unregister network object '/fi/w1/wpa_supplicant1/Interfaces/1/Networks/0' Oct 11 17:48:02 panhandle wpa_supplicant[772]: No keys have been configured - skip key clearing Oct 11 17:48:02 panhandle wpa_supplicant[772]: State: ASSOCIATING -> DISCONNECTED Status 17 is "WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA"; basically the AP responds that it can't deal with the new association; more or less meaning it's already to capacity with clients and can't handle more. (See http://lists.shmoo.com/pipermail/hostap/2004-May/006769.html) FWIW, I'm using the ieee_802_11_defs.h file from the wpasupplicant code to match status and reason codes, if you're interesting in knowing what the numbers mean ;) (http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob;f=src/common/ieee802_11_defs.h). You can similarly get the NM reason/status codes here: http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/include/NetworkManager.h. The best I can suggest at this point is to contact McGill's network administrators; discuss the matter with them (pointing out this bug report), and see if there's more information that can be retrieved from comparing your system's logs with logs from the APs and auth system. I'll keep this bug report open in case there really is something wrong with wpasupplicant, but for now nothing clearly indicates it's the case. Furthermore, you may wish to test this all with the latest release of Ubuntu: Oneiric Ocelot (11.10), since there were some changes in NM and wpasupplicant which might help (and it's just a good idea to give it a shot anyway). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/872578 Title: The infamous "deauthenticating by local choice (reason=3)" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/872578/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
