Cannot connect automatically to access point when using hostap_pci

[Sitsofe Wheeler]

Binary package hint: network-manager

Description of the problem:
Using NetworkManager to connect to an unencrypted access point fails when using the hostap_pci driver.

Steps to reproduce:
1. Start Ubuntu.
2. Log in.
3. Wait for a list of access points to be shown in nm-applet.
4. Select the access point you wish to connect to.

Expected result:
Animated NetworkManager icon to occur followed (after 5 seconds) by one green light then a second green light. Working internet connection to have been established.

Actual result:
No green lights ever occur. After some time network manager gives up and no internet connection has been established.

How reproducible is this problem:
It is reproducible every time.

Additional information:
I have hand compiled the orinoco_pci drivers from 2.6.24 (as Ubuntu doesn't ship them) and NetworkManager successfully connects when those are loaded instead of hostap_pci. It is possible to manually (via iwconfig, ifconfig and dhclient) to connect to the access point using hostap_pci. Here is what NetworkManager prints to the daemon.log:

Apr 4 13:40:09 g NetworkManager: <debug> [1207312809.251213] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/net_p
ci_1260_3873').
Apr 4 13:40:09 g NetworkManager: <debug> [1207312809.266961] nm_hal_device_added(): New device added (hal udi is '/org/freedesktop/Hal/devices/net_0
0_09_5b_2f_69_00').
Apr 4 13:40:09 g NetworkManager: <info> wlan0: Device is fully-supported using driver 'hostap_pci'.
Apr 4 13:40:09 g NetworkManager: <info> wlan0: driver supports SSID scans (scan_capa 0x01).
Apr 4 13:40:09 g NetworkManager: <info> nm_device_init(): waiting for device's worker thread to start
Apr 4 13:40:09 g NetworkManager: <info> nm_device_init(): device's worker thread started, continuing.
Apr 4 13:40:09 g NetworkManager: <info> Now managing wireless (802.11) device 'wlan0'.
Apr 4 13:40:09 g NetworkManager: <info> Deactivating device wlan0.
Apr 4 13:40:11 g avahi-daemon[4677]: Registering new address record for fe80::209:5bff:fe2f:6900 on wlan0.*.
Apr 4 13:40:23 g NetworkManager: <info> User request to enable wireless.
Apr 4 13:40:34 g NetworkManager: <info> SWITCH: no current connection, found better connection 'wlan0'.
Apr 4 13:40:34 g NetworkManager: <info> Will activate connection 'wlan0/Wireless'.
Apr 4 13:40:34 g NetworkManager: <info> Device wlan0 activation scheduled...
Apr 4 13:40:34 g NetworkManager: <info> Activation (wlan0) started...
Apr 4 13:40:34 g NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Apr 4 13:40:34 g NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Apr 4 13:40:34 g NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Apr 4 13:40:34 g NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Apr 4 13:40:34 g NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Apr 4 13:40:34 g NetworkManager: <info> Activation (wlan0/wireless): access point 'Wireless' is unencrypted, no key needed.
Apr 4 13:40:36 g NetworkManager: <info> SUP: sending command 'INTERFACE_ADD wlan0^I^Iwext^I/var/run/wpa_supplicant0^I'
Apr 4 13:40:36 g NetworkManager: <info> SUP: response was 'OK'
Apr 4 13:40:36 g NetworkManager: <info> SUP: sending command 'AP_SCAN 1'
Apr 4 13:40:36 g NetworkManager: <info> SUP: response was 'OK'
Apr 4 13:40:36 g NetworkManager: <info> SUP: sending command 'ADD_NETWORK'
Apr 4 13:40:36 g NetworkManager: <info> SUP: response was '0'
Apr 4 13:40:36 g NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 ssid 576972656c657373'
Apr 4 13:40:36 g NetworkManager: <info> SUP: response was 'OK'
Apr 4 13:40:36 g NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 key_mgmt NONE'
Apr 4 13:40:36 g NetworkManager: <info> SUP: response was 'OK'
Apr 4 13:40:36 g NetworkManager: <info> SUP: sending command 'ENABLE_NETWORK 0'
Apr 4 13:40:36 g NetworkManager: <info> SUP: response was 'OK'
Apr 4 13:40:36 g NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Apr 4 13:40:42 g NetworkManager: <info> Old device 'wlan0' activating, won't change.
Apr 4 13:41:14 g last message repeated 3 times
Apr 4 13:41:36 g last message repeated 2 times
Apr 4 13:41:36 g NetworkManager: <info> Activation (wlan0/wireless): association took too long (>60s), failing activation.
Apr 4 13:41:36 g NetworkManager: <info> Activation (wlan0) failure scheduled...
Apr 4 13:41:36 g NetworkManager: <info> Activation (wlan0) failed for access point (Wireless)
Apr 4 13:41:36 g NetworkManager: <info> Activation (wlan0) failed.
Apr 4 13:41:36 g NetworkManager: <info> Deactivating device wlan0.

Version information:
Ubuntu hardy (development branch)
network-manager 0.6.6-0ubuntu5
linux-image-2.6.24-12-generic 2.6.24-12.22

[Sitsofe Wheeler (sitsofe)]

Forgot to mention that the card is a Netgear MA311 PCI card (Intersil Prism 2.5 chipset) with 1.7.4 secondary firmware. NetworkManager can use hostap_pci to connect to the access point without trouble under Gutsy.

lspci:
00:0f.0 Network controller: Intersil Corporation Prism 2.5 Wavelan chipset (rev 01)

[J. David Smith (godsinventor)]

Same problem here. EXACTLY the same. The only difference is the card (I think). I have never been able to figure what brand my card is other than Intersil Prism 2.5 chipset.

BTW, I have a HP Pavilion ze4200 1.8GHz Intel Pentium 4M Laptop running Hardy. (sorry for all the processor details, there is no other way to differentiate it.)

[Sitsofe Wheeler (sitsofe)]

J. David Smith:
Which firmware is your card running:
dmesg | grep STA:
should tell you. Additionally which model of access point are you connecting to?

[J. David Smith (godsinventor)]

The access point is a Linksys WRT54G wireless router.

1.7.3 primary and 1.8.4 station I believe (I will double check tomorrow when I get back, my computer is not accessible ATM)

[Sitsofe Wheeler (sitsofe)]

The access point for me is a WRT54GL. If I connect to the access using manual configuration (which has its own issues, see Bug #185209) then a working connection is established.

J. David Smith:
I'd be surprised if the primary was 1.7.3...

[J. David Smith (godsinventor)]

My station firmware is 1.8.2

wifi0: STA: id=0x1f v1.8.2

[J. David Smith (godsinventor)]

The latest batch of updates fixed mine. I am writing this from my ubuntu partition on my laptop. Now if only I could get openSUSE to hold a connection...

My advice: find a wired connection and grab the latest updates.

[Alexander Sack (asac)]

Please attach the following _complete_ syslogs as file attachments to this bug:
 1. syslog from hardy taken after you reproduced the connect failure
 2. syslog from gutsy taken after you reproduced the connect success

Further, attach the output of nm-tool.

Thanks,
 - Alexander

[Alexander Sack (asac)]

Remember, given that we are close to the release, quick responses appreciated ;)

[J. David Smith (godsinventor)]

I can put on the output of nm-tool, but not of the other two. I have no access to my computer ATM, so will put it up later.

[Sitsofe Wheeler (sitsofe)]

asac:
I can't do that until I am at my (home) machine in a few hours time. I installed the latest round of kernel updates this morning but I haven't had a chance to see whether the problem has gone away yet...

[Sitsofe Wheeler (sitsofe)]

Note neither kernel nor other updates resolved my issue. I had to set things to connect manually with the caveat mentioned in bug #178775 )

[Adrian Bridgett (adrian-bridgett)]

The problem is the line:
Apr 4 13:40:36 g NetworkManager: <info> SUP: sending command 'INTERFACE_ADD wlan0^I^Iwext^I/var/run/wpa_supplicant0^I'

you _need_ to tell wpa_supplicant to use hostap, not wext.

Sadly, ubuntu had a patch for this, but it has been dropped:

+ * drop driver specific tweaks assuming that wext should be fine for most drivers nowadays
+ - drop debian/patches/14-j-hostap-supplicant-driver.patch
...

Getting the old diff from:
http://packages.ubuntu.com/feisty/net/network-manager
and apply the wpa_driver bit fixes the problem. Diff attached. I should say that this has only been tested on a _Debian_ desktop running 2.6.25.

[Sitsofe Wheeler (sitsofe)]

Rumour has it that the wext interface should work too - http://lists.shmoo.com/pipermail/hostap/2007-August/016085.html .

[ChristophM (cm-hardware-software-elsewhere)]

Seems that I have exactly the same problem since I "up"graded to 8.04 this morning. See excerpt of daemon.log (some names and IDs specific to my computer altered)

[ChristophM (cm-hardware-software-elsewhere)]

I ran into the same problem ... seems that this confirms the existence of the bug.

[ChristophM (cm-hardware-software-elsewhere)]

I have to contradict the rumor in http://lists.shmoo.com/pipermail/hostap/2007-August/016085.html
In version 7.10, WPA encryption worked; "up"grading to 8.04 broke it - I can't even connect to an UNencrypted linksys WRT54GX2.

[Sitsofe Wheeler (sitsofe)]

ChristophM:
Not even manually?

[Sitsofe Wheeler (sitsofe)]

ChristophM:
Additionally your hardware is completely different to that reported in this bug (from your description you are using an Intel card). If you really are using the old ipw3945 driver as opposed to the iwlwifi driver you may want to switch and see if you get better results. ipw* has been deprecated by Intel. The symptoms might be the same but I suspect the cause is different so it might be wise to put your issue in a separate bug report and link to it from here).

[ChristophM (cm-hardware-software-elsewhere)]

Now that you're asking ... my kern.log seems to indicate an iwl* driver for the intel 3945 chip:

May 1 07:39:24 [name] kernel: [ 34.118082] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.0
May 1 07:39:24 [name] kernel: [ 34.118085] iwl3945: Copyright(c) 2003-2007 Intel Corporation

So far, I see no indication that my bug does not have the same cause that yours has.
This is the first time I use launchpad, so I don't know the best practices hereabouts.
Seems to me that the bugs are related enough to warrant getting looked at simultaneously.

I heard from at least one other user that he has a similar problem, with yet different hardware.

[Sitsofe Wheeler (sitsofe)]

ChristophM;
That last part is interesting. Are you able to to connect to your access point using manual configuration / non roaming mode?

[Sitsofe Wheeler (sitsofe)]

One other thing worth pointing out is that the iwlwifi drivers have never (to the best of my knowledge) a wpa_supplicant other than wext (and older versions of Ubuntu were using wext for them).

[ChristophM (cm-hardware-software-elsewhere)]

After a few installfests and the help of some local guys who remind me of the maker of Pascal, I found the source of _my_ problem:
The new wifi driver seems to output the 802.11g frequencies as supported rates and the 802.11b frequencies as extended rates.
My wireless access point expects it the other way around and burps:
"Association denied due to requestiong station not supporting all of the datarates in the BSSBasicServiceSet Parameter (0x0012)"
I finally followed Sitsofe Wheeler's advice and made this its own bug#242727.

I don't know yet what driver causes the problem, though.

[Alexander Sack (asac)]

still an issue in intrepid?

[Alexander Sack (asac)]

well hostap_pci doesnt exist there anymore afaik. we have a bunch of atheros regressions on top unfortunately. but this particular bug most likely doesnt apply anymore.

[Sitsofe Wheeler (sitsofe)]

Alexander:
GIve me a chance to reply - a few minutes is not enough : )

 I've just checked the Intrepid live CD and I see a hostap_pci in the modules directory.
http://packages.ubuntu.com/intrepid/i386/linux-image-2.6.27-7-generic/filelist

Where did you see that it had been removed?

[Alexander Sack (asac)]

ok, so the issue still exists in intrepid? could you try the ~network-manager PPA version of the network-manager please?

[Alexander Sack (asac)]

also attach a fresh tail of the wpa_supplicant.log that captures a timed out connect attempt. Thanks!

[Sitsofe Wheeler (sitsofe)]

It's going to be months (about mid December) before I am with the machine that shows the problem again so it's going to be a while before I can get those logs to you.

[Alexander Sack (asac)]

ok setting to incomplete in the meantime.

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

 We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!