First discovered in Ubuntu 12.10 Alpha 2 Installed upstream kernel behavior is the same Wireless WPA security does not automatically connect Instead on cold boot it "Disconnects" Response to Systems Settings > Network very very slow Select connection in menu 20 seconds later next menu with network name 30 to 40 seconds later to respond so I can select connect Maybe 10 seconds later to actually connect Acer Aspire 1 netbook, 1.66 gHz Intel Atom N455 dual processor Note, wireless WPA. On the same network same security Broadcom doesn't connect automatically either, but it actually does respond to mouse selections on systems settings > network in a reasonable manner. https://bugs.launchpad.net/bugs/1019083 where the bug person requested installing upstream kernel and where the request to file this bugzilla bug. Let me know if I can supply any additonal info or try anything. Thanks, Jerry
It is not at all clear to me that this is a kernel problem -- especially if you see the same thing with both Broadcom and Intel hardware. It seems more likely to be a problem with your local network. Perhaps you could post the output from dmesg immediately after a connection failure?
Created attachment 74941 [details] dmesg with upstream kernel showing 79 second gap before authenticate This time 3.5.0-30500rc5 did connect after sitting for 79 seconds. What was it waiting for? Will submit a couple other dmesg also
Created attachment 74951 [details] dmesg from kernel 3.2.0-24 connects immediately dmesg showing automatic connection, ubuntu 12.04 kernel, no pause, conect comes right up. Jerry
Created attachment 74961 [details] dmesg kernel 3.5.0-1 showing not ready? The 3.5.0-030500rc5 previously mentioned is on ubutnu 12.10 installed 03 July. The 3.5.0-1 is from ubuntu repros installed 25 June, some complaint about not ready? I could try different kernels or different installs or several boots to see if there is any difference. Any idea what the 79 second gap in the dmesg for the 3.5.0-030500rc5 is? Thanks, Jerry Jerry
Created attachment 74991 [details] dmesg after 4 minute wait for automatic connect did manual network connect From cold boot at 3:31 gave up waiting for "automatic" connect and did systems settings > network. Note dmesg something about "denied" fpr "epollwakup" whatever that means at that time. Sluggish response to network, other, and connect selections taking over a minute At 4:56 manual connect finally worked. Should "epollwakup" be issued at boot? If so, why was it "denied"? Thanks, Jerry
This bug is marked as "NEEDINFO". What info is needed? Comment #1 from John Linville asked for some dmessg output which I have provided. Jerry
Created attachment 75041 [details] dmesg from an actual successful auto connect Here's the dmesg from an actual auto connect. Looks a lot different on the last few lines: [ 54.914767] EXT3-fs (sdb7): using internal journal [ 54.914789] EXT3-fs (sdb7): mounted filesystem with ordered data mode [ 86.970915] wlan0: authenticate with 00:0f:b3:b0:d6:3c [ 86.984789] wlan0: send auth to 00:0f:b3:b0:d6:3c (try 1/3) [ 86.987028] wlan0: authenticated [ 86.987506] wlan0: waiting for beacon from 00:0f:b3:b0:d6:3c [ 87.140071] wlan0: associate with 00:0f:b3:b0:d6:3c (try 1/3) [ 87.143199] wlan0: RX AssocResp from 00:0f:b3:b0:d6:3c (capab=0x431 status=0 aid=1) [ 87.143210] wlan0: associated [ 87.145928] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Will try again for success/failure. Takes a shutdown - wait - reboot cycle to do it. Jerry
Created attachment 75101 [details] dmesg from over 2 minute wait for "automatic connection" dmesg shows mo activity from "54" yto "185". Visually a 2 min 20 second wait for connect. Will attach syslog subsequently.
Created attachment 75111 [details] syslog from over 2 minute wait for "automatic connection" At tail end syslog shows activity for wlan0. I can't correlate the time stamps with the dmesg for the same event. Any ideas? Thanks, Jerry
I'm sorry, but I don't see any evidence of a kernel problem here. The kernel has no concept of an "automatic connection". Something in userland (probably NetworkManager in your case) has to tell the kernel what AP to use. In every case above, the authentication happens on the first try, followed immediately by the association on the first try. I don't see any significant delay being introduced by the kernel, and there are not even any retries. At worst, the kernel could be taking a while to scan -- but I don't see any evidence of an abnormally long scan either. It seems like you are unhappy with how long it takes for your system to boot, login, and establish a connection through NetworkManager. You'll have to pursue that with your distribution (i.e. Ubuntu).