I'm using NetworkManager in Fedora Core 5 with an ipw2200 wireless card and a Linksys WRT54G access point. The AP is set up for WPA2 Personal security. Once in a while the connection just works the first time. Most of the time, it usually just times out, or else it appears to connect but then the connection goes down again. I'm not sure what to do to debug this much further, maybe somebody can see something interesting from the output. I'm attaching some /var/log/messages output that shows some of these (zipped up, otherwise it's too big to post to this list). assocfail.txt shows the case where it just times out. I'm not sure what's going on there, it seems somebody (I presume the supplicant) is expecting something to happen that doesn't. (I really wish the supplicant's output would be a bit clearer to the uninformed as to what exactly it was waiting for, a lot of the time it just seems to stop at some point expecting something to happen.) The essential part is:Mar 27 21:07:24 localhost NetworkManager: <information> wpa_supplicant(4245): Trying to associate with 00:0c:41:bb:86:e2 (SSID='Robman' freq=0 MHz) Mar 27 21:07:24 localhost NetworkManager: <information> wpa_supplicant(4245): CTRL_IFACE monitor send - hexdump(len=42): 2f 76 61 72 2f 72 75 6e 2f 4e 65 74 77 6f 72 6b 4d 61 6e 61 67 65 72 2f 77 70 61 5f 63 74 72 6c 5f 34 32 33 31 2d 31 00 00 00 Mar 27 21:07:24 localhost NetworkManager: <information> wpa_supplicant(4245): Cancelling scan request Mar 27 21:07:24 localhost NetworkManager: <information> wpa_supplicant(4245): WPA: clearing own WPA/RSN IE Mar 27 21:07:24 localhost NetworkManager: <information> wpa_supplicant(4245): Automatic auth_alg selection: 0x1 Mar 27 21:07:24 localhost NetworkManager: <information> wpa_supplicant(4245): RSN: using IEEE 802.11i/D9.0 Mar 27 21:07:24 localhost NetworkManager: <information> wpa_supplicant(4245): WPA: Selected cipher suites: group 16 pairwise 16 key_mgmt 2 Mar 27 21:07:24 localhost NetworkManager: <information> wpa_supplicant(4245): WPA: clearing AP WPA IE Mar 27 21:07:24 localhost NetworkManager: <information> wpa_supplicant(4245): WPA: set AP RSN IE - hexdump(len=22): 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 Mar 27 21:07:24 localhost NetworkManager: <information> wpa_supplicant(4245): WPA: using GTK CCMP Mar 27 21:07:24 localhost NetworkManager: <information> wpa_supplicant(4245): WPA: using PTK CCMP Mar 27 21:07:32 localhost NetworkManager: <information> eth1: link timed out. Mar 27 21:07:41 localhost NetworkManager: <information> Activation (eth1/wireless): association took too long (>20s), failing activation.
assocfail2.txt shows the second situation where the connection goes up but then goes down again immediately. I'm not sure what is going on there either. For some reason, the kernel reports "link becomes ready" and dhclient goes and obtains an IP address while the supplicant is still messing around with the keys. Maybe the keys were already set from a previous attempt? Then after the supplicant has been fiddling around with the keys, the link goes down, then comes back up a few seconds later.. Finally NM seems to give up on the entire process. assocsuccess.txt shows a case where after bouncing around a bit it finally settles down and stays connected. Can anyone make much sense out of this? I can try and provide more info if needed.
Attachment:
nm-output.zip
Description: Zip compressed data