[iwl4965] wireless support broken since 0.6.6~rc2

[Martin-Éric Racine]

Since network-manager 0.6.6~rc2 entered Hardy this morning, wireless connections no longer work. Selecting any host among the list of access point shown in the applet fails. This is a serious regression.

[Mikael Gerdin (mgerdin)]

I'm sorry if I'm hijacking your bug-report now but I think I have the same issue.
The problem seems to be with the patch 41t_nm_device_wireless_index_ctrl_sockets_by_run_count.patch
I'll attach my daemon.log to show what I think is the issue.
The problem seems to arise when I try to switch from one network to another, the first "run" of wpa_supplicant works, but when nm tries to start another then it can't find its control socket.

[Mikael Gerdin (mgerdin)]

Oh, and I'm using version 0.6.6~rc2-0ubuntu3 of network-manager

[Martin-Éric Racine (q-funk)]

ubuntu1 was the one that failed for me. ubuntu3 seems to have fixed it.

[gpothier (gpothier)]

It's also broken here, with 0ubuntu3. The kde nm applet just asks for password again and again, but connection is never established.
The relevant (I guess) part of the log is that:
Mar 6 11:03:40 tadzim NetworkManager: <info> SUP: sending command 'INTERFACE_ADD eth1^I^Iwext^I/var/run/wpa_supplicant0^I'
Mar 6 11:03:40 tadzim NetworkManager: <info> SUP: response was 'OK'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: sending command 'AP_SCAN 1'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: response was 'OK'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: sending command 'ADD_NETWORK'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: response was '0'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 ssid 74616e676f'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: response was 'OK'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 scan_ssid 1'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: response was 'OK'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 key_mgmt NONE'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: response was 'OK'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 wep_key0 <key>'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: response was 'OK'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 wep_tx_keyidx 0'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: response was 'OK'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: sending command 'ENABLE_NETWORK 0'
Mar 6 11:03:41 tadzim NetworkManager: <info> SUP: response was 'OK'
Mar 6 11:03:41 tadzim NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) complete.
Mar 6 11:03:41 tadzim avahi-daemon[5371]: Joining mDNS multicast group on interface eth1.IPv6 with address fe80::213:ceff:fe3a:3deb.
Mar 6 11:03:41 tadzim avahi-daemon[5371]: New relevant interface eth1.IPv6 for mDNS.
Mar 6 11:03:41 tadzim avahi-daemon[5371]: Registering new address record for fe80::213:ceff:fe3a:3deb on eth1.*.
Mar 6 11:03:44 tadzim NetworkManager: <info> Old device 'eth1' activating, won't change.

Then it keeps saying the last message until the next time the applet asks for password.
I can connect manualy (iwconfig/dhclient) without problem

[Jason Straight (jason-jeetkunedomaster)]

I'm not getting anywhere with madwifi drivers either with WPA, not sure if this is relevant or not, but:

NetworkManager: <info> Activation (ath0) Stage 2 of 5 (Device Configure) complete.
Trying to associate with 00:14:bf:06:ff:bd (SSID='jrs' freq=2442 MHz)
NetworkManager: <info> Old device 'ath0' activating, won't change.
Authentication with 00:00:00:00:00:00 timed out.

Authentication with 00:00:00:00:00:00 should match the AP BSSID it's associating with - right?

[Russ Dill (russ-dill)]

I'm using madwifi too, and its broken. It just keeps spinning and spinning with no green light and eventually gives up. If I look at the command line I can see that not only has the access point been found, but running dhclient ath0 gets an IP address and the connection "works", until network-manager gives up and brings down the interface.

[Daniel Newman (dmnewman)]

It's broken for me with version 0.6.6~rc2-0ubuntu3.

The relevant syslog is:
NetworkManager: <info> Updating allowed wireless network lists.
NetworkManager: <info> SWITCH: no current connection, found better connection 'ath0'.
dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.reason
NetworkManager: <info> Will activate connection 'ath0/my_net'.
NetworkManager: <info> Device ath0 activation scheduled...
NetworkManager: <info> Activation (ath0) started...
NetworkManager: <info> Activation (ath0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager: <info> Activation (ath0) Stage 1 of 5 (Device Prepare) started...
NetworkManager: <info> Old device 'ath0' activating, won't change.
NetworkManager: <info> Old device 'ath0' activating, won't change.
NetworkManager: <info> Activation (ath0) Stage 2 of 5 (Device Configure) scheduled...
NetworkManager: <info> Activation (ath0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager: <info> Activation (ath0) Stage 2 of 5 (Device Configure) starting...
NetworkManager: <info> Activation (ath0/wireless): access point 'my_net' is encrypted, but NO valid key exists. New key needed.
NetworkManager: <info> Activation (ath0) New wireless user key requested for network 'my_net'.
NetworkManager: <info> Activation (ath0) Stage 2 of 5 (Device Configure) complete.
NetworkManager: <info> Activation (ath0) New wireless user key for network 'my_net' received.
NetworkManager: <info> Activation (ath0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager: <info> Activation (ath0) Stage 1 of 5 (Device Prepare) started...
NetworkManager: <info> Activation (ath0) Stage 2 of 5 (Device Configure) scheduled...
NetworkManager: <info> Activation (ath0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager: <info> Activation (ath0) Stage 2 of 5 (Device Configure) starting...
NetworkManager: <info> Activation (ath0/wireless): access point 'my_net' is encrypted, and a key exists. No new key needed.
NetworkManager: <info> retry to connect to global supplicant socket (try=1)
NetworkManager: <info> SUP: sending command 'INTERFACE_ADD ath0^I^Iwext^I/var/run/wpa_supplicant0^I'
NetworkManager: <info> SUP: response was 'OK'
NetworkManager: <info> SUP: sending command 'AP_SCAN 2'
NetworkManager: <info> SUP: response was 'OK'
NetworkManager: <info> SUP: sending command 'ADD_NETWORK'
NetworkManager: <info> SUP: response was '0'
NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 ssid 7161706c5d5c6574'
NetworkManager: <info> SUP: response was 'OK'
NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 scan_ssid 1'
NetworkManager: <info> SUP: response was 'OK'
NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 proto WPA'
NetworkManager: <info> SUP: response was 'OK'
NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 key_mgmt WPA-PSK'
NetworkManager: <info> SUP: response was 'OK'
NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 psk <key>'
NetworkManager: <info> SUP: response was 'OK'
NetworkManager: <info> SUP: sending command 'ENABLE_NETWORK 0'
NetworkManager: ...

[Martin-Éric Racine (q-funk)]

The constant we notice above is that it mainly affects users of mad-wifi, which is one of the last drivers that hasn't been merged into the kernel tree or converted to the unified wifi stack design used since kernel 2.6.24. While I haven't looked at the upstream chnagelog, I wouldn't be surprised if 0.6.6 breaks on madwifi simply because it has migrated to the unified wifi stack as a method of interacting with the interfaces.

[gpothier (gpothier)]

I'm having the problem with the ipw2200 driver, so it's not madwifi-specific.

[danda (dan-osc)]

I'm having the problem. Also atheros. Thinkpad t61.

[Andrew Hutchings (linuxjedi)]

Same here, madwifi on a macbook pro using Hardy 64bit.

[Mikael Gerdin (mgerdin)]

I'm experiencing this with the iwl3945 driver, in amd64 and I've only tried with knetworkmanager.

[Alexander Sack (asac)]

hi all,

it doesn't really help if you dump your confirmation about "wireless is so broken" in this generic bug report. Each of you: please open a _new_ bug (please don't assume that you have found a duplicate unless you know the details) , If its a duplicate some skilled bug triager will figure that out for you.

OK, so if you file a new bug, please

 1. name the chipset in the bug title (e.g. [ipw3945] cannot connect with network manager 0.6.6-0ubuntu1) - be sure to name the exact network-manager package version.
 2. attach a the _complete_ /var/log/syslog (be sure that a failed connect attempt is in there as well).
 3. if you can connect manually post the steps and any config files involved in this as well.

this bug is invalid now.

Thanks for caring,

 - Alexander

[Russ Dill (russ-dill)]

No, thank you for caring.

[Martin-Éric Racine (q-funk)]

It doesn't really help if you simply invalidate a bug and assume that everyone should have known what info is needed, instead of requesting the additional info you need to properly respond to the report. This bug is marked as incomplete.

And since I was the one to originally file this report, here's my relevant hardware info:

0c:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)

Originally filed against 0.6.6~rc2-0ubuntu1.

[Alexander Sack (asac)]

Martin,

ok, please attach your syslog as well (taken after a failed connect attempt).

Thanks,

 - Alexander

[Alexander Sack (asac)]

Martin-Eric, please provide the information i asked for above. Further, are you trying to connect to a hidden ssid?

[Alexander Sack (asac)]

importance high as this is a regression. milestoning (which wll be void if we cannot get all the required information).

[Christopher Sachs (amitofu)]

Cannot connect to wireless networks with network-manager-0.6.6-0ubuntu1 on first-gen MacBook with atheros chipset. Manually configuring the interface works fine. Attaching syslog.

[Andrew Hutchings (linuxjedi)]

My access point is visible and WPA encrypted. I have disabled all encryption on the access point (a Linksys WRT54GS) to test this and symptoms still persist.

I have tested this on my MacBook Pro second-gen (first core 2 duo edition) with the i386 and x86_64 editions of Hardy, both have the same problem. I am using the latest trunk checkout of madwifi.

Same driver works on OpenSUSE 10.3 on the same laptop and 0.6.5 of network-manager on Hardy.

Syslog excerpt attached.

[Javier Cabezas (javier-cabezas)]

It is not working here (First-gen Macbook + network-manager 0.6.6-0ubuntu2). I have tried WEP, WAP and no encryption. However, it works if I configure it manually (iwconfig + dhclient).

The symptoms are the same as the previously reported:

NetworkManager: <info> Activation (ath0): Stage 2 of 5 (Device Configure) complete.
NetworkManager: <info> Old device 'ath0' activating, won't change.
NetworkManager: <info> Old device 'ath0' activating, won't change.
NetworkManager: <info> Old device 'ath0' activating, won't change.
NetworkManager: <info> Activation (ath0/wireless): association took too long (> 120s), failing activation.
NetworkManager: <info> Activation (ath0/wireless): failure scheduled...
NetworkManager: <info> Activation (ath0/wireless): failed for access point (XXX)
NetworkManager: <info> Activation (ath0/wireless): failed.
NetworkManager: <info> Deactivating device ath0

[Bruno Santos (bsantos)]

Have you tried the latest update (0.6.6-0ubuntu2)?

* resurrect and adapt driver tweaks to new code base for ath_pci cards
    (LP: #202453).
    - add debian/patches/42a_ath_pci_supplicant_tweaks.patch
    - update debian/patches/series

[Javier Cabezas (javier-cabezas)]

Yes, I have tried it but it does not work

[Russ Dill (russ-dill)]

On Wed, Mar 19, 2008 at 6:12 AM, Bruno Santos <email address hidden> wrote:
> Have you tried the latest update (0.6.6-0ubuntu2)?
>
> * resurrect and adapt driver tweaks to new code base for ath_pci cards
> (LP: #202453).
> - add debian/patches/42a_ath_pci_supplicant_tweaks.patch
> - update debian/patches/series
>

Fixes the ath_pci breakage I had.

[Christopher Sachs (amitofu)]

network-manager-0.6.6-0ubuntu2 solves the problem on my first-gen MacBook. nm-applet is fully functional again. Great work and thanks for the quick turnaround. Three cheers for Alexander!

[Bruno Santos (bsantos)]

Christopher, are you using madwifi SVN? Does it connect after a suspend
or do you have to reload the modules?

[Andrew Hutchings (linuxjedi)]

Yep, 0.6.6-0ubuntu2 fixes it for my macbook pro. Cheers guys

[Martin-Éric Racine (q-funk)]

Alexander, in my case, the problem resolved itself with the next, so I
am no longer able to provide some of the information, such as logs.

On Mon, Mar 17, 2008 at 1:42 PM, Alexander Sack <email address hidden> wrote:
> Martin-Eric, please provide the information i asked for above. Further,
> are you trying to connect to a hidden ssid?
>
> ** Changed in: network-manager (Ubuntu)
> Status: New => Incomplete
>
> ** Summary changed:
>
> - wireless support broken since 0.6.6~rc2
> + [iwl4965] wireless support broken since 0.6.6~rc2
>
> --
> [iwl4965] wireless support broken since 0.6.6~rc2
> https://bugs.launchpad.net/bugs/199066
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Martin-Éric Racine
http://q-funk.iki.fi

[Pierre Slamich (pierre-slamich)]

Even with 0.6.6-0ubuntu2, I still have the issue. I have a kernel related problem (or so it seems) as changing the kernel seems to solve the issue.
I've commented on it at : https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/178703/comments/13

[Andrew Hutchings (linuxjedi)]

Pierre:
Which driver are you using? If its the subversion checkout of madwifi you need to build it for every kernel update.

[lod (altoas)]

for me with any driver, madwifi and ndiswrapper. madwifi if from svn (i'm using patched version for ar5007 support) but i've build it clean after beta install

[Pavel Aleksandrov (afterburner-mail)]

just upgraded to 8.04 Beta. I see all the networks, but when I try to connect to any of them, NetworkManager hangs with the cpu on 100%, I can only kill it. I am using b43 firmware, so I am not sure it's relevant for this bug report.

P.S. It's the same no matter if there is encryption or not on the wireless network.

This is what syslog says:

Mar 22 16:55:03 after-laptop dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason
Mar 22 16:55:03 after-laptop NetworkManager: <debug> [1206197703.197705] nm_device_802_11_wireless_get_activation_ap(): Forcing AP 'localhost'
Mar 22 16:55:03 after-laptop NetworkManager: <info> User Switch: /org/freedesktop/NetworkManager/Devices/eth1 / localhost
Mar 22 16:55:03 after-laptop NetworkManager: <info> Deactivating device eth1.
Mar 22 16:55:05 after-laptop NetworkManager: <info> Device eth1 activation scheduled...
Mar 22 16:55:05 after-laptop NetworkManager: <info> Deactivating device eth0.
Mar 22 16:55:05 after-laptop dhclient: There is already a pid file /var/run/dhclient.eth0.pid with pid 7108
Mar 22 16:55:05 after-laptop dhclient: killed old client process, removed PID file
Mar 22 16:55:05 after-laptop dhclient: wmaster0: unknown hardware address type 801
Mar 22 16:55:05 after-laptop dhclient: wmaster0: unknown hardware address type 801
Mar 22 16:55:05 after-laptop dhclient: DHCPRELEASE on eth0 to 192.168.1.1 port 67
Mar 22 16:55:05 after-laptop avahi-daemon[5611]: Withdrawing address record for 192.168.1.4 on eth0.
Mar 22 16:55:05 after-laptop avahi-daemon[5611]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.4.
Mar 22 16:55:05 after-laptop avahi-daemon[5611]: Interface eth0.IPv4 no longer relevant for mDNS.
Mar 22 16:55:06 after-laptop avahi-daemon[5611]: Withdrawing address record for fe80::219:b9ff:fe56:14e on eth0.
Mar 22 16:55:06 after-laptop NetworkManager: <info> Activation (eth1) started...
Mar 22 16:55:06 after-laptop NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled...
Mar 22 16:55:06 after-laptop NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) started...
Mar 22 16:55:06 after-laptop NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) scheduled...
Mar 22 16:55:06 after-laptop NetworkManager: <info> Activation (eth1) Stage 1 of 5 (Device Prepare) complete.
Mar 22 16:55:06 after-laptop NetworkManager: <info> Activation (eth1) Stage 2 of 5 (Device Configure) starting...
Mar 22 16:55:06 after-laptop NetworkManager: <info> Activation (eth1/wireless): access point 'localhost' is unencrypted, no key needed.
Mar 22 16:55:07 after-laptop NetworkManager: <WARN> nm_signal_handler(): Caught signal 11. Generating backtrace...
Mar 22 16:55:07 after-laptop NetworkManager: ******************* START **********************************
Mar 22 16:55:07 after-laptop NetworkManager: (no debugging symbols found)
Mar 22 16:55:07 after-laptop NetworkManager: Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Mar 22 16:55:07 after-laptop NetworkManager: (no debugging symbols found)
Mar 22 16:55:07 after-laptop las...

[Stuart Read (sread)]

Pavel:
I have the exact same problem, also with b43 firmware. I have uploaded my daemon.log to Bug #145652, and the output and symptoms are identical.

[Mikael Gerdin (mgerdin)]

Pavel and Stuart:
What you're experiencing is probably bug #204768 which is caused by a regression in HAL, please check that you have hal version >= 0.5.11~rc2-1ubuntu2

[Klass (dan-djohnson)]

Mikael:

I have the same problem as Pavel and Stuart and my HAL version is 0.5.11~rc2-1ubuntu2.

Additionally after attempting to connect to a wireless network, NetworkManager crashes.

This is what syslog says:

Mar 22 12:10:30 minotaur NetworkManager: <WARN> nm_signal_handler(): Caught signal 11. Generating backtrace...
Mar 22 12:10:30 minotaur NetworkManager: ******************* START **********************************
Mar 22 12:10:31 minotaur NetworkManager: (no debugging symbols found)
Mar 22 12:10:31 minotaur NetworkManager: Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Mar 22 12:10:31 minotaur NetworkManager: (no debugging symbols found)
Mar 22 12:10:31 minotaur last message repeated 10 times
Mar 22 12:10:31 minotaur NetworkManager: [Thread debugging using libthread_db enabled]
Mar 22 12:10:31 minotaur NetworkManager: [New Thread 0xb7b52720 (LWP 5247)]
Mar 22 12:10:31 minotaur NetworkManager: [New Thread 0xb7350b90 (LWP 5588)]
Mar 22 12:10:31 minotaur NetworkManager: [New Thread 0xb7b51b90 (LWP 5430)]
Mar 22 12:10:31 minotaur NetworkManager: (no debugging symbols found)
Mar 22 12:10:31 minotaur last message repeated 9 times
Mar 22 12:10:31 minotaur NetworkManager: 0xb7f51410 in __kernel_vsyscall ()
Mar 22 12:10:31 minotaur NetworkManager: ******************* END **********************************

[Mikael Gerdin (mgerdin)]

Unfortunately I don't think that installing the debug symbols packages helps network-manager generate a useful backtrace. If someone who's experiencing this feels up to it you could compile network manager locally with DEB_BUILD_OPTIONS="nostrip" and that should hopefully result in some useful debug symbols in the backtrace.
The instructions for rebuilding a debug-version can be found here:
https://wiki.ubuntu.com/DebuggingProgramCrash (since network-manager has its own way of generating a backtrace you have to use the "Prior Ubuntu versions" way.

[Stephan Wüthrich (ubuntu-runway)]

I have exactly the same problem and debug output like Pavel.

If i configure the wlan via System->Network-Admin, the wlan works perfect.

DELL Inspiron 8600 with b43 firmware. 8.04 BETA

Thank's to solve this :-)

[Florian Zeitz (florian-zeitz)]

I think the new problem is actually the one documented in Bug #204868 (including a fix).
Well actually it is reported in like 20 bugs, which are all linked in a wild net of duplicate marks, but #204868 is the only one to include a patch (which works).

[Stuart Read (sread)]

Thank you Florian for the link, this does indeed solve the 100% cpu freeze in network-manager for the b43 driver.

[Steve Langasek (vorlon)]

The original bug for which this bug report was opened, iwl4965 breakage in NM 0.6.6~rc2, is reported as resolved; I'm therefore marking this bug as "fixed released".

If you are experiencing problems with NM and you are using anything other than the iwl4965 driver, please do NOT follow up to this bug. Mixing information from unrelated problems in a single bug report makes it very difficult to ever close out *any* bug reports. Either find an open bug report whose description matches your symptoms and subscribe to that, or if necessary, file a new bug report. If in doubt, please just file a new bug report - marking bug reports as duplicates is much easier for us than trying to winnow information out of an overloaded report.