Kernel Bug Tracker – Bug 37612
[ath5k] losing connection after about 200 seconds
Last modified: 2013-12-23 13:50:11 UTC
Created attachment 62202 [details]
dmesg showing the network loss at about 266s
[Note: bug splitted from bug #34992]
I am able to connect to the wireless network (using NetworkManager from Ubuntu 11.04), but after about 200s I lose the connection and I am no longer able to reconnect. I have to wait about half an hour (rebooting PC isn't sufficient, it looks like as the AP blacklist my PC) then I can reconnect for another ~200s and so on.
I am using 188.8.131.52 + the patch for bug #34992 + patch
http://patches.aircrack-ng.org/ath5k_regdomain_override.patch (to use 30dB
power but it makes no difference) + https://patchwork.kernel.org/patch/103589/ (to avoid the -1 error with airmon).
I enabled the following ath5k options:
I have to say I connect to a public AP with WPA which is far from my home (I
get about 70~90dB). I am attaching my dmesg, note the gap between 53-266 where the network worked, then it fails and try to reconnect without success.
Also note that this is a regression for me since it worked up to some time ago, but it's probably not a kernel regression since I also tried with the same 2.6.37 kernel that I was sure it worked before. Anyway I find it strange that it works for 200s and then it disconnect.
Have you tried any other APs? It is entirely possible that the AP is simply disconnecting you and refusing to reconnect for some time, possibly due to having too many simultaneous connections.
Is that dmesg complete? It seems to go from "associated" to "authenticating" without ever reporting a disconnection in between. You might also attach your wpa_supplicant.log file.
Created attachment 62572 [details]
syslog showing the network loss at about 294s
> It is entirely possible that the AP is simply
> disconnecting you and refusing to reconnect for some time,
> possibly due to having too many simultaneous connections.
I am sure I was the only one connecting to it.
> Is that dmesg complete? It seems to go from "associated" to "authenticating"
> without ever reporting a disconnection in between. You might also attach your
> wpa_supplicant.log file.
The dmesg was complete. I have no wpa_supplicant.log file (I use NetworkManager) but the attached syslog file contains a lot more info, including NetworkManager output and some ath5k debug output. Here the network connection lasted between 99 and 294.
Created attachment 62582 [details]
syslog with connection retries on second - very near - AP
(In reply to comment #1)
> Have you tried any other APs?
I am trying now with a different multi-SSID AP, I am just under it (40 dB).
I tried on a first SSID (Ateneo) and was unable to connect, these were showed 4x times:
[26090.091504] wlan0: direct probe to 00:1a:1e:c6:95:c2 (try 1/3)
[26090.288218] wlan0: direct probe to 00:1a:1e:c6:95:c2 (try 2/3)
[26090.488146] wlan0: direct probe to 00:1a:1e:c6:95:c2 (try 3/3)
[26090.688162] wlan0: direct probe to 00:1a:1e:c6:95:c2 timed out
I then tried on its second SSID (Ospiti) and it eventually connected. I then tried changing again the SSID many times, and now I can always connect, however it often require > 1 retries:
[26605.388110] wlan0: authenticate with 00:1a:1e:c6:95:c0 (try 1)
[26605.588083] wlan0: authenticate with 00:1a:1e:c6:95:c0 (try 2)
[26605.590043] wlan0: authenticated
[26605.590171] wlan0: associate with 00:1a:1e:c6:95:c0 (try 1)
[26605.788139] wlan0: associate with 00:1a:1e:c6:95:c0 (try 2)
[26605.798524] wlan0: RX AssocResp from 00:1a:1e:c6:95:c0 (capab=0x421 status=0 aid=2)
[26605.798532] wlan0: associated
syslog using this second AP is attached.
Jun 11 18:41:59 fabio-mac wpa_supplicant: CTRL-EVENT-DISCONNECTED bssid=00:1d:8b:6a:04:a4 reason=0
Reason 0 is supposed to be "reserved" -- not sure what that means...
Just for fun, can we see the contents of /etc/NetworkManager/dispatcher.d/01ifupdown?
Created attachment 62592 [details]
> Just for fun, can we see the contents of
I noticed this interesting patch on 184.108.40.206 which sounds like my same problem, however on a different driver:
If this is still present in modern kernels please update the bug