Atheros, networkmanager fails
I have a strange wireless problem. I run an up to date Debian Etch on a T42p thinkpad. I had wireless working using network-manager with madwifi. For some reason it stopped working. I just figured some update broke it. lspci shows: Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) The strange thing is that my thinkpad developed a system board problem and had to be repaired. My hard drive was put into a T42 loaner. The loaner T42 had an Atheros AR5211 controller. Wireless worked with the loaner under network-manager. I noticed it used ath1 instead of ath0 like my regular laptop always did. When I got my regular laptop back, wireless under Linux still didn't work and it was using ath0 again. I verified that wireless does work when I boot into Windows. What I don't understand is why for no reason did my original laptop wireless quit working? Why did the loaner use ath1 instead of ath0? Is ath0 somehow tied to the controller hardware address of my regular laptop so the loaner with a different controller hardware address used ath1? Is there some bad configuration information stored somewhere for ath0 causing it to not work? If so, how can I clear it out. I use udev. Network-manager is nice when it works but if it doesn't work, it seems hard to debug since it hides everything. Any ideas on how to debug this problem? madwifi-source 1:0.9.2+r1842.20061207-2 network-manager 0.6.4-6 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: networkmanager fails to associate (ipw3945)
Dan Williams wrote: Right; there are cases that I don't understand where the association results between NM and wpa_supplicant are different. We need to find out why. It could be that NM is not passing the right options to wpa_supplicant, or that there are bugs in either NM or wpa_supplicant. We need to find out where the difference is. So in conclusion, maybe we remove the || nm_device_is_activating (dev) from supplicant_status_cb() and just ignore the link timeout while activating. But the real question is, _why_ would the auth/assoc take 20 seconds, and _why_ is the driver sending disconnect events during the attempt, especially if the association doesn't complete within the 20s timeout? What _really_ needs to be fixed here, the driver or NM? the interessting thing is that everything but nm can connect to the app (wpa_supplicant,windows and even the wii) It might be a driver bug I am currently using ipw3945 maybe I will try again this weekend with iwlwifi (if I get it to build) and report. Thanks, Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Network Manager, misbehaves
I have two issues with Network Manager that I think are related, but perhaps not. Note: Using Ubuntu Edgy First, I have the Network Monitor applet showing that I have a connection, as of now, connection strength is at 86%. At the same time Network Manager (0.6.3) shows connection strength at 52%. (25' unobstructed line of sight) I understand this is a known issue with Atheros chipset cards. And I saw at one point a fix. The problem is that the fix required hacking some element of the NM source and recompiling. While I'd be willing to give such a fix a try, the entire discussion assumed at least some modicum of programing ability. I'm willing to learn, but that's not me. The other issue is that I understand the fix would then break the ability to have Ubuntu auto-majically update when necessary. I'm not sure that's a good idea. Second problem: My wifi connection will periodically drop connection. This will happen both on my office WIFI or at Home, Both APs are configured for WPA personal. The router / DHCP server at work is configured for 1 day lease times, so I doubt that is the issue. It will also happen more often when I move to a location, office or home, that has a lower signal strength. It has also happened on Open WIFI. For example (and this was really frustrating) I was at a hotel at a business conference. There was paid wifi in the rooms and free in the lobby. So naturally, I went to the lobby, where NM could see both the GuestRm ESSID and the Lobby ESSID. NM showed about 35% signal strength for the former and 20% for the latter. (Even though I was sitting in the lobby.) I could force a connection to Lobby, but would promptly (2-3 minutes) be dropped, and NM would try to access the pay service. One more data point: Since I had work that had to be done, I rebooted into XP, forced the Lobby connection, and windows was able to stay connected. So, if this signal strength discrepancy issue is the culprit, then I'd like to fix it. But, If the signal strength that NM reports has no effect on NM's functioning, then I suppose I don't care. Does anyone know? Also, anyone have any ideas about why NM drops the connection periodically? Especially if it is not about signal strength? Thanks, Patton ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager, misbehaves
On Mon, 2007-02-12 at 18:42 -0800, Patton Echols wrote: I have two issues with Network Manager that I think are related, but perhaps not. Note: Using Ubuntu Edgy First, I have the Network Monitor applet showing that I have a connection, as of now, connection strength is at 86%. At the same time Network Manager (0.6.3) shows connection strength at 52%. (25' unobstructed line of sight) I understand this is a known issue with Atheros chipset cards. And I saw at one point a fix. The problem is that the fix required hacking some element of the NM source and recompiling. While I'd be willing to give such a fix a try, the entire discussion assumed at least some modicum of programing ability. I'm willing to learn, but that's not me. The other issue is that I understand the fix would then break the ability to have Ubuntu auto-majically update when necessary. I'm not sure that's a good idea. Second problem: My wifi connection will periodically drop connection. This will happen both on my office WIFI or at Home, Both APs are configured for WPA personal. The router / DHCP server at work is configured for 1 day lease times, so I doubt that is the issue. It will also happen more often when I move to a location, office or home, that has a lower signal strength. It has also happened on Open WIFI. For example (and this was really frustrating) I was at a hotel at a business conference. There was paid wifi in the rooms and free in the lobby. So naturally, I went to the lobby, where NM could see both the GuestRm ESSID and the Lobby ESSID. NM showed about 35% signal strength for the former and 20% for the latter. (Even though I was sitting in the lobby.) I could force a connection to Lobby, but would promptly (2-3 minutes) be dropped, and NM would try to access the pay service. One more data point: Since I had work that had to be done, I rebooted into XP, forced the Lobby connection, and windows was able to stay connected. So, if this signal strength discrepancy issue is the culprit, then I'd like to fix it. But, If the signal strength that NM reports has no effect on NM's functioning, then I suppose I don't care. Does anyone know? Signal strength has no effect on NM's function precisely because every driver used to report it differently. We harmonized most of the other drivers, but madwifi still reports oddly. I don't know if that's because their not following my interpretation of the WEXT spec or what, since the WEXT spec is so muddled there. Also, anyone have any ideas about why NM drops the connection periodically? Especially if it is not about signal strength? Run 'iwevent' and see if the driver is sending IWAP events with a BSSID of 00:00:00:00:00:00 when you get disconnected. If so, that's a driver problem. Logs would also help here, they are dumped to the normal syslog location, usually /var/log/messages. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager, misbehaves
On 02/12/2007 06:59 PM, Dan Williams wrote: On Mon, 2007-02-12 at 18:42 -0800, Patton Echols wrote: I have two issues with Network Manager that I think are related, but perhaps not. Note: Using Ubuntu Edgy SNIP Also, anyone have any ideas about why NM drops the connection periodically? Especially if it is not about signal strength? Run 'iwevent' and see if the driver is sending IWAP events with a BSSID of 00:00:00:00:00:00 when you get disconnected. If so, that's a driver problem. Logs would also help here, they are dumped to the normal syslog location, usually /var/log/messages. Dan Thanks for your help. I'm posting back to the lists in case these are of interest to others. I started iwevent before giving NM a the key for home wpa. Also attached is the contents of /var/log/messages from the last boot. It's quite lengthy, but I included it all since I really don't know what it all means. Here is the output of iwevent: [EMAIL PROTECTED]:~$ iwevent Waiting for Wireless Events from interfaces... 19:57:15.499168 ath0 Set Mode:Managed 19:57:15.559925 ath0 Set ESSID:Echo1 19:57:15.636517 ath0 New Access Point/Cell address:00:0F:B5:69:5D:24 19:57:15.671114 ath0 Custom driver event:MLME-MICHAELMICFAILURE.indication(keyid=4 unicast addr=00:05:4e:50:a9:0f) 20:01:20.503306 ath0 Scan request completed 20:06:31.186724 ath0 Scan request completed 20:09:48.003526 ath0 New Access Point/Cell address:Not-Associated 20:09:48.106943 ath0 Set ESSID:off/any 20:09:57.037356 ath0 Set ESSID: 20:09:59.039589 ath0 Set Encryption key:off 20:09:59.039816 ath0 Set Mode:Managed 20:10:00.064758 ath0 Set Mode:Managed 20:10:00.079356 ath0 Set ESSID:Echo1 20:10:00.099247 ath0 New Access Point/Cell address:00:0F:B5:69:5D:24 20:14:39.594215 ath0 New Access Point/Cell address:Not-Associated 20:14:39.695878 ath0 Set ESSID:off/any 20:14:48.614065 ath0 Set ESSID: 20:14:50.608515 ath0 Set Encryption key:off 20:14:50.608763 ath0 Set Mode:Managed 20:14:51.632866 ath0 Set Mode:Managed 20:14:51.653501 ath0 Set ESSID:Echo1 20:14:51.672535 ath0 New Access Point/Cell address:00:0F:B5:69:5D:24 20:20:01.076088 ath0 Scan request completed 20:22:57.911874 ath0 New Access Point/Cell address:Not-Associated 20:22:58.014394 ath0 Set ESSID:off/any 20:23:06.944491 ath0 Set ESSID: 20:23:08.947044 ath0 Set Encryption key:off 20:23:08.947271 ath0 Set Mode:Managed 20:23:09.971949 ath0 Set Mode:Managed 20:23:09.991090 ath0 Set ESSID:Echo1 20:23:10.011054 ath0 New Access Point/Cell address:00:0F:B5:69:5D:24 20:24:56.351613 ath0 New Access Point/Cell address:Not-Associated 20:24:56.452847 ath0 Set ESSID:off/any 20:25:05.371048 ath0 Set ESSID: 20:25:07.366159 ath0 Set Encryption key:off 20:25:07.366395 ath0 Set Mode:Managed 20:25:08.402876 ath0 Set Mode:Managed 20:25:08.428584 ath0 Set ESSID: 20:25:10.429689 ath0 Set Encryption key:off 20:25:10.429921 ath0 Set Mode:Managed 20:25:39.727089 ath0 Set ESSID: 20:25:41.729064 ath0 Set Encryption key:off 20:25:41.729296 ath0 Set Mode:Managed 20:25:42.768664 ath0 Set Mode:Managed 20:25:42.787454 ath0 Set ESSID:Echo1 20:25:42.809215 ath0 New Access Point/Cell address:00:0F:B5:69:5D:24 Here is the contents of /var/log//messages from boot time: Feb 12 19:51:48 Mycroft syslogd 1.4.1#18ubuntu6: restart. Feb 12 19:51:48 Mycroft kernel: Inspecting /boot/System.map-2.6.17-11-generic Feb 12 19:51:49 Mycroft kernel: Loaded 22866 symbols from /boot/System.map-2.6.17-11-generic. Feb 12 19:51:49 Mycroft kernel: Symbols match kernel version 2.6.17. Feb 12 19:51:49 Mycroft kernel: No module symbols loaded - kernel modules not enabled. Feb 12 19:51:49 Mycroft kernel: [17179569.184000] Linux version 2.6.17-11-generic ([EMAIL PROTECTED]) (gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)) #2 SMP Thu Feb 1 19:52:28 UTC 2007 (Ubuntu 2.6.17-11.35-generic) Feb 12 19:51:49 Mycroft kernel: [17179569.184000] BIOS-provided physical RAM map: Feb 12 19:51:49 Mycroft kernel: [17179569.184000] BIOS-e820: - 0009f000 (usable) Feb 12 19:51:49 Mycroft kernel: [17179569.184000] BIOS-e820: 0009f000 - 000a (reserved) Feb 12 19:51:49 Mycroft kernel: [17179569.184000] BIOS-e820: 000dc000 - 0010 (reserved) Feb 12 19:51:49 Mycroft kernel: [17179569.184000] BIOS-e820: 0010 - 2ff6 (usable) Feb 12 19:51:49 Mycroft kernel: [17179569.184000] BIOS-e820: 2ff6 - 2ff78000 (ACPI data) Feb 12 19:51:49 Mycroft kernel: [17179569.184000] BIOS-e820: 2ff78000 - 2ff7a000 (ACPI NVS) Feb 12 19:51:49 Mycroft kernel: [17179569.184000] BIOS-e820: 2ff8 - 3000 (reserved) Feb 12 19:51:49
