Latest working kernel version: never Earliest failing kernel version: never Distribution: fedora 10 Hardware Environment: 03:00.0 Network controller: Atheros Communications Inc. AR5418 802.11abgn Wireless PCI Express Adapter (rev 01) Software Environment: NetworkManager Problem Description: - ath9k wont to establish connection from first attemp. i tried to do it under windows and os x on same hardware - everyting going fast in about 1-3 sec. under linux connection can established for 3-10 secs. wlan0: authenticate with AP 00:19:cb:8c:57:af wlan0: authenticate with AP 00:19:cb:8c:57:af wlan0: authentication with AP 00:19:cb:8c:57:af timed out wlan0: authenticate with AP 00:19:cb:8c:57:af wlan0: authenticate with AP 00:1c:f0:bd:01:06 wlan0: authenticated wlan0: associate with AP 00:1c:f0:bd:01:06 wlan0: RX AssocResp from 00:1c:f0:bd:01:06 (capab=0x31 status=0 aid=1) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: disassociating by local choice (reason=3) wlan0: authenticate with AP 00:1c:f0:bd:01:06 wlan0: authenticate with AP 00:1c:f0:bd:01:06 wlan0: authenticated wlan0: associate with AP 00:1c:f0:bd:01:06 wlan0: RX ReassocResp from 00:1c:f0:bd:01:06 (capab=0x31 status=0 aid=1) wlan0: associated Steps to reproduce: reboot machine/kill x and try to get in wireless network
small correction: - problem happens only after reboot/suspend. and never after killing X. - after reboot/suspend often NetworkManager ask creditenals for one time, rare for 0-10 times.
Let me get this straight -- you AR5418 is able to establish connection with your AP upon a fresh bootup. But then after a soft reboot (sudo reboot) or suspend your card has issue connecting with your AP? If I have understood things correctly then please: http://wireless.kernel.org/en/users/Documentation/Reporting_bugs After that, please use wpa_supplicant manually to establish connection to your AP. Let me know how that goes.
Also what AP do you have and what type of settings are you using with it? Is it an 802.11n AP, if so are you enabling only 802.11n connections or mixed, also what HT configuration are you using Ht20 or HT40? Are you using encryption, if so what type?
Fresh bootup/soft reboot/suspend resume produce long auth process. Always it's done with described issue. My AP is dwl-g700ap with only 11abg standarts, and no 11n support. That why i never heard about HT20/40 and do not know what is that. My AP configured as AP with Mixed mode (probably not only G mode), with WPA2-PSK auth. There is wpa clean log: ./[root@axet-laptop axet]# ./wpa.sh CTRL-EVENT-SCAN-RESULTS Trying to associate with 00:1c:f0:bd:01:06 (SSID='wifi.local' freq=2412 MHz) Authentication with 00:1c:f0:bd:01:06 timed out. CTRL-EVENT-SCAN-RESULTS Trying to associate with 00:1c:f0:bd:01:06 (SSID='wifi.local' freq=2412 MHz) Associated with 00:1c:f0:bd:01:06 WPA: Key negotiation completed with 00:1c:f0:bd:01:06 [PTK=CCMP GTK=CCMP] CTRL-EVENT-CONNECTED - Connection to 00:1c:f0:bd:01:06 completed (auth) [id=0 id_str=] d[root@axet-laptop axet]# dhclidnet -d wlan0 bash: dhclidnet: command not found [root@axet-laptop axet]# dhclient -d wlan0 Internet Systems Consortium DHCP Client 4.0.0 Copyright 2004-2007 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/wlan0/00:19:e3:d3:7b:51 Sending on LPF/wlan0/00:19:e3:d3:7b:51 Sending on Socket/fallback DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 192.168.54.1 bound to 192.168.54.5 -- renewal in 100651 seconds. [axet@axet-laptop ~]$ cat wpa.sh #!/bin/bash /usr/sbin/wpa_supplicant -Dwext -iwlan0 -c /home/axet/wpa.conf -K [axet@axet-laptop ~]$ cat wpa.conf ctrl_interface=/var/run/wpa_supplicant network={ scan_ssid=0 ssid="wifi.local" proto=WPA2 key_mgmt=WPA-PSK pairwise=CCMP group=CCMP psk="1q2w3e4r" } Note: suspend resume do not produce long auth and timeouts when i run test from console.
If your association takes long and you would like to fix that I recommend to get the latest ath9k: http://wireless.kernel.org/en/users/Drivers/ath9k#Getthelatestath9kdriver
same for wireless tree: sometimes after resume/reboot networkmanager baddly ask for enter creditionals, and auth take about 3-5 sec (for association) and 5 for dhcp address.
If its the same for the wireless-testing tree you can try manually with the latest wpa_supplicant (without Network Manager). See how long that takes to associate. Keep in mind there is a difference here between the driver -- the supplicant and the userspace applet you would use to connect (network manager). So in between you have a lot of things in the middle. If your grudge is connection time after resume you want to find out which is the one that takes longer in the chain and report that to see if it can be improved. Having metrics for this would be interesting in gerenal for the linux-wireless list.