[ndiswrapper] [wg511] fails to associate

I'm having the same problem, and it's driving me nuts! Thank you for reporting it. (Though I haven't tried the older kernel - can do if you think it will be helpful)

wpa_supplicant can't authenticate, even when I try manually with the EXACT same wpa_supplicant.conf from a working computer! (Running 7.10, I think - on a ndiswrapper'ed card) It keeps trying over and over, blacklisting, and unblacklisting, just like that. HOWEVER, the nm-applet works fine! It only fails on static configuration, and I've tried every configuration, even trying different drivers instead of wext. For the life of me, I can NOT figure out what arguements nm is passing to wpa_supplicant to make it to work. Atheros card, proprietary driver.

 If you kill wpa_supplicant, and then manually bring it up, it will work. But, no amount of tweaking seems to make it come up correctly on bootup, even if you add the required "auto" to /etc/network/interfaces.

wpa_supplicant does not seem to run against kernel 2.6.24. With 2.6.22 everything works fine. In my case the problem appears with madwifi.

/sbin/wpa_supplicant -B -P /var/run/wpa_supplicant.ath0.pid -i ath0 -D madwifi -C /var/run/wpa_supplicant

Log:
ioctl[SIOCSIWPMKSA]: No such device
ioctl[SIOCSIWMODE]: No such device
ioctl[SIOCGIFFLAGS]: No such device
ioctl[SIOCGIWRANGE]: No such device
ioctl[IEEE80211_IOCTL_SETPARAM]: No such device
ioctl[SIOCSIWAP]: No such device
ioctl[SIOCGIFFLAGS]: No such device
Initializing interface 'ath0' conf 'N/A' driver 'madwifi' ctrl_interface '/var/run/wpa_supplicant' bridge 'N/A'
Initializing interface (2) 'ath0'
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: KEY_RX entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE entering state INITIALIZE
EAP: EAP entering state DISABLED
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
Could not configure driver to use managed mode
Could not set interface 'ath0' UP
WEXT: Operstate: linkmode=1, operstate=5
wpa_driver_madwifi_init: failed to set wpa_supplicant-based roaming
WEXT: Operstate: linkmode=0, operstate=6
Failed to initialize driver interface
Failed to add interface ath0
Cancelling scan request
Cancelling authentication timeout

Hi,

I have a similar problem. I installed Hardy amd64 edition and cannot get my wireless connection (I have rtl818L chipset on the wireless).

I managed to install the patched drivers from: www.willdaniels.co.uk/index.php/blog/tech-stuff but when I try to connect using e.g. kwlan it says that wpa supplicant is not started.

I will be able to post logs later when I get back home.

If wpa_supplicant does not seem to run against kernel 2.6.24. as described in comment#4 can you plase make it work?

Thanks,

Lukasz

I can also confirm that wpa_supplicant is not working with Hardy. It was working with Gutsy. This is a iwl4965 card and configuration through knetworkmanager. Killing wpa_supplicant after boot seems to make it work though.

Here are my logs.

hope this helps...

let me know, if you need anything else

Lukasz

I have a similar problem :
ipw3945 + wpasupplicant in Gutsy worked fine to connect to my university's wireless (MSCHAPV2) network
iwl3945 + wpasupplicant in Hardy doesn't work
see :
https://bugs.launchpad.net/linux/+bug/220640

Hi ubuntu_daemon,

Which distribution of Hardy you use? mine is amd64

Lukasz

I also upgraded from gutsy and wpa_suplicant stopped working. Booting the gutsy kernel (2.6.22-14-generic) fixes the problem. (I'm using 32bit intel before you ask!). This is with ipw3945.

I have the same config as I was using with gutsy, which I manually set up because I couldn't get it working with the gui tools in gutsy. In /etc/network/interfaces I have:

 iface eth1 inet static
 address 192.168.1.8
 netmask 255.255.255.0
 gateway 192.168.1.1
 wpa-conf /etc/wpa_supplicant.conf
 wpa-driver wext
 auto eth1

And in /etc/wpa_suplicant.conf I have:
  network={
        ssid="speedy"
        psk=_______my_personal_key_______
  }

I have tried killing and manually starting wpa_suplicant, but that did not work either. It just kept failing to associate. I also tried deleting my manual setup and using the hardy network setup, but that didn't work either.

to wookash :

Ubuntu Hardy x86 live cd

Hi,

I have solved this with a great help from WIll Daniels (thanks again, mate).

I installed rtl8185L drivers patched by Will from:

http://www.willdaniels.co.uk/blog

I needed to set /etc/network/interfaces:

auto lo
iface lo inet loopback

auto wlan0
iface wlan0 inet dhcp
wpa-driver ipw
wpa-conf /etc/wpa_supplicant.conf

And wpa_supplicant.conf:

network={
  ssid="**********"
 proto=RSN
 key_mgmt=WPA-PSK
 pairwise=CCMP
 group=CCMP
 psk=*************************************************************
}

And all runs smoothly, loads on boot and works with hidden SSID on Hardy amd64 edition.

Lukasz

One amendment:

The hidden SSID is not working yet, but I get connected when broadcasting so far.

Additionally, I had to place the following line (removing any other entries for rtl8180 drivers) in modules.dep:

/lib/modules/2.6.24-16-generic/kernel/wireless/r8180.ko: /lib/modules/2.6.24-16-generic/kernel/wireless/ieee80211-rtl.ko /lib/modules/2.6.24-16-generic/kernel/wireless/ieee80211_crypt_ccmp-rtl.ko /lib/modules/2.6.24-16-generic/kernel/wireless/ieee80211_crypt_tkip-rtl.ko /lib/modules/2.6.24-16-generic/kernel/wireless/ieee80211_crypt_wep-rtl.ko /lib/modules/2.6.24-16-generic/kernel/wireless/ieee80211_crypt-rtl.ko

Where /lib/modules/2.6.24-16-generic/kernel/wireless/ is the patch where I copied the built drivers.

Then they load on starting up the wlan0, so thanks to the config in /etc/network/interfaces if I understand it correctly. So they load when the wireless interface starts.

All in all I have come to the final conclusion how I made it work for me:

1) install Will's patched drivers

2) adding ieee80211_crypt_ccmp-rtl to the /etc/modules

3) configure interfaces and wpa_supplicant.conf as above

Then it loads fine on boot and works fine with hidden SSID. I have added ap_scan=2 and scan_ssid=1 as below to the wpa_supplicant file, but have not tested if this determines it works with hidden SSID (my guess would be it does not but since it does not hurt..)

ap_scan=2

network={
    ssid="*********"
    scan_ssid=1
    proto=WPA2
     #proto=RSN <-- one setting proto=wpa2 does the job
    key_mgmt=WPA-PSK
    #pairwise=CCMP <-- one setting proto=wpa2 does the job
    #group=CCMP <-- one setting proto=wpa2 does the job
    psk=***************************************
}

I'm also experiencing the same issue of being unable to associate with a WPA-PSK AP after updating from Gutsy to Hardy. Wireless setup with WG511v1 and ndiswrapper (tried both versions 1.50 & 1.52). Also tried with Network Manager and Wicd but same symptoms and problem. Unable to obtain the correct key to connect with the AP. Wireless setup and configuration worked under Gutsy but unable to get it to work under Hardy.

5.10 with manual config seems to perform well for me. Easy to compile. I installed it, set everything static & manual in /etc/network/interfaces with an old fashioned /etc/wpa_supplicant.conf. This seems to work great. Be sure to disable the network manager. Sorry - I don't mean to turn a bug report into a help forum, but hopefully that will assist somebody.

unconfirming this bug.
Christan Haberli: Your symptoms are clearly different to what has been presented in this bug. I therefore think your change to this bug status was unqualified.

Michael: The looks looks pretty much like a wrong password.

Could you please recheck your password? Please also try different other encryption schemes (WPA2/AES, WPA2/TKIP, WPA/AES and WPA/TKIP). Please also attach a full debug wpasupplicant log for the different encrpytion modes.

I have to admit that I don't really understand what actually happens here. I currently suspect a bug in your wifi driver in some encryption scheme, to be honest.

To other contributors in this bug: If you do not use ndiswrapper, you are very likely to not be affected by this bug. Please file another bug describing you network hardware!

I still have Gutsy 7.10, and am having this problem.

* Compaq r4010us laptop
* Broadcom 4306
* Using ndiswrapper with 'wext' in the command line
* Linksys WRT54GS v1.0 Firmware v4.50.6
* Attempting WPA(1)-PSK with static IP
* 'network-manager' and 'gnome-network-manager' uninstalled, as they were fouling up my manual IP settings; erasing them.

I can connect fine with encryption disabled. Enabled, I have had successful connections twice, but it's not easy to get them and I have yet to nail down the procedure to get it, as the nature of this bug makes landing on the right sequence of steps difficult.

The two times I did connect with WPA, I decided to 'play around a bit' and see exactly what the key to it was, and I permanently lost the connection until the next boot, but mind you that it will not connect at boot even though I'm using the rc.local script. I still have to play around with it to connect.

So, apparently, once it goes down, only a reboot and more fiddling solves it. I have tried the following 'resets', to no avail:

* /etc/init.d/networking restart
* /etc/init.d/dbus restart

I have tried ap_scan set to 0, 1 and 2. I have invoked wpa_supplicant in two combinations:

1) -Bw without -d or -dd
2) -w with -dd

I will be playing with it more this week as I have time (and hair to pull), and I'll report what I find.

I have the exact same problem. I've experienced it on both 2.6.24-16 and 2.6.24-17. My ndiswrapper info is:

bcmwl5 : driver installed
 device (14E4:4311) present (alternate driver: ssb)

Ndiswrapper and wpa_suppliant versions:
ii ndisgtk 0.8.3-1 graphical frontend for ndiswrapper (installa
ii ndiswrapper-common 1.50-1ubuntu1 Common scripts required to use the utilities
ii ndiswrapper-utils-1.9 1.50-1ubuntu1 Userspace utilities for the ndiswrapper Linu
ii wpasupplicant 0.6.0+0.5.8-0ubuntu2 Client support for WPA and WPA2 (IEEE 802.11

Here's what syslog has to say:

May 27 08:46:48 epsilon NetworkManager: <info> Updating allowed wireless network lists.
May 27 08:46:48 epsilon NetworkManager: <info> SWITCH: no current connection, found better connection 'wlan0'.
May 27 08:46:48 epsilon dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/wlan0 for sub-path wlan0.dbus.get.reason
May 27 08:46:48 epsilon NetworkManager: <info> Will activate connection 'wlan0/Shambhala'.
May 27 08:46:48 epsilon NetworkManager: <info> Device wlan0 activation scheduled...
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) started...
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0/wireless): access point 'Shambhala' is encrypted, but NO valid key exists. New key needed.
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) New wireless user key requested for network 'Shambhala'.
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) New wireless user key for network 'Shambhala' received.
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
May 27 08:46:48 epsilon NetworkManager: <info> Activation (wlan0/wireless): access point 'Shambhala' is encrypted, and a key exists. No new k...

I also installed wpasupplicant_0.6.3-1_amd64.deb from the Debian archive. It fails with this new version too.

As suggested by Reinhard Tartler above I have opened a new bug for my problem with the intel ipw3945 and wpa_supplicant.

It is here:
  https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/237290

I can confirm this problem for rtl8187 card. I have a custom compiled 2.6.22 kernel and wpa_supplicant works fine using ndiswrapper and wext. When I move to 2.6.24 I can only make unencrypted network working. Wpa_supplicant can not associate. I compiled ndiswrapper from source and tried both 1.50 and 1.52.
Bus 006 Device 002: ID 0bda:8189 Realtek Semiconductor Corp.

uboltun <email address hidden> writes:
> I can confirm this problem for rtl8187 card.

Please open a seperate bug for other drivers. this bug is clearly about
the ndiswrapper driver, and only about ndiswrapper. thanks.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

bug #238031 is probably the same issue as you are experiencing here. That bug might have information for you guys here.

More info and observations as posted on the <a href="http://ndiswrapper.sourceforge.net/joomla/index.php?/component/option,com_fireboard/Itemid,27/func,view/id,1337/catid,3/">NDISwrapper Forum</a>:

Worked in Ubuntu 7.10 - Not in 8.04 2008/04/30 03:26

I'm experiencing an issue of being unable to associate with a WPA-PSK AP after updating from Ubuntu Gutsy to Hardy. Wireless setup with WG511v1 and ndiswrapper (tried both versions 1.50 & 1.52). Also tried with Network Manager and Wicd but same symptoms and problem. Seems as though ndiswrapper is unable to obtain the correct key to connect with the AP. Wireless setup and configuration worked under Gutsy but unable to get it to work under Hardy. The native prism54 drivers for the Netgear WG511v1 have been blacklisted, and here's the pertinent info:

ndiswrapper version 1.50-1ubuntu1 (hardy)

wpasupplicant version 0.6.0+0.5.8-0ubuntu2 (hardy)

gnome-keyring version 2.22.1-1 (hardy)

libpam-gnome-keyring version 2.22.1-1 (hardy)

network-manager version 0.6.6-0ubuntu5 (hardy)

wicd version 1.4.2-1 (apt.wicd.net)

:~$ ndiswrapper -v
utils version: '1.9', utils version needed by module: '1.9'
module details:
filename: /lib/modules/2.6.24-16-generic/ubuntu/misc/ndiswrapper/ndiswrapper.ko
version: 1.52
vermagic: 2.6.24-16-generic SMP mod_unload 586

:~$ ndiswrapper -l
netwg511 : driver installed
device (1260:3890) present (alternate driver: prism54)

[Edit#1] Noticed that the keyring management has changed quite a bit in Hardy. Don't know if this change has any effect on ndiswrapper's operation and/or interface with the revised keyring functions.

Post edited by: tl3000, at: 2008/04/30 14:53

[Edit#2] Verified that ndiswrapper & netwg511 driver works for open APs.

Post edited by: tl3000, at: 2008/05/01 05:08

[Edit#3] More info but still no resolution yet...

Tested with the following latest updates without success:

gnome-keyring version 2.22.2-0ubuntu1 (hardy-updates)

libpam-gnome-keyring version 2.22.2-0ubuntu1 (hardy-updates)

:~$ ndiswrapper -v
utils version: '1.9', utils version needed by module: '1.9'
module details:
filename: /lib/modules/2.6.24-18-generic/misc/ndiswrapper.ko
version: 1.53
vermagic: 2.6.24-18-generic SMP mod_unload 586

---------------------------------------------------------------------
Testing of the WPA_Supplicant configuration reveals:

:~$ sudo wpa_supplicant -iwlan0 -c/etc/wpa_supplicant.conf -Dndiswrapper -w -dd
Initializing interface 'wlan0' conf '/etc/wpa_supplicant.conf' driver 'ndiswrapper' ctrl_interface 'N/A' bridge 'N/A'
Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf'
Reading configuration file '/etc/wpa_supplicant.conf'
Line: 1 - start of a new network block
ssid - hexdump_ascii(len=3):
65 72 6e ern
proto: 0x1
key_mgmt: 0x2
PSK - hexdump(len=32): [REMOVED]
Priority group 0
id=0 ssid='ern'
Initializing interface (2) 'wlan0'
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: KEY_RX entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE entering state INITIALIZE
EAP: EAP entering state DISABLED
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
SIOCGIWRANGE: WE(compiled)=22 WE(source)=21 enc_capa=0xf
cap...

Since this issue seems highly driver related, and more people seem to experience it, I've confirmed the wpasupplicant bugtask and opened a new bugtask for the kernel, in the hope they can provide further input on this.

Same here.
I have a WG511 v2, I use ndiswrapper and marvell driver in Ubuntu Hardy 8.04 and it works correctly only in an unprotcted wifi net.
With WPA on, it's impossible to associate with the AP.
Other info here: http://robotsaregodless.blogspot.com/2008/06/ubuntu-wg511-v2-ndiswrapper.html

Same here.
IPN2220 with ndiswrapper
AMD64
It was working with Gusty.

--
Chri

I have made several things and now it works (i dont' know why....).

I suggest from the network manager to totally delete the association (mouse right button on the network manager icon in the tray)
and to reconnect.

--
Chri

I can confirm this with an IPN 2220 card (ndiswrapper, network manager). The problem is not with ndiswrapper, or network manager, as far as I can tell, as I am using the hardy versions with a gutsy setup and they work fine.

My history with the problem:
1) upgraded from gutsy to hardy; suddenly no longer to connect to previously working access point on wpa network.
2) clean install of hardy: wpa unable to connect
3) clean install of gutsy with ndiswrapper and network manager added from the hardy disk: access works fine. All updates have been applied to gutsy installation as well.

As said before, the issue seems to be due to an incompatibility between the current ndiswrapper/wpasupplicant and the hardy kernel (2.6.24). Indeed, on my clean install of hardy it works fine if I'm using the gutsy kernel (2.6.22), otherwise it doesn't.

We should try using the intrepid kernel, maybe it has been fixed (I haven't had a look at the changelogs though).

Problem is back for me, i can not connect anymore
(IPN 2220 card (ndiswrapper, network manager) and AMD64)

On the same machine, i have another chipset
Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
and this chipset can connect with the Access Point (my network manager configuration is not changed).

Hello,

Could anyone summarize what the solution is at this point, if any?

Thanks.

I've got the same problem with Netgear USB dongle WG111v3. I couldn't connect with WPA encryption in 2.6.24, but connected fine with 2.6.22 kernel. Someone on a Google-group found out a solution, which works for me. He changed the nice value of wpa-supplicant-daemon to the lowest possible 19.

http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/9807e14552464331

I don't know why this works, but it does for me. Unfortunately i can't use WICD any more, because on every connect it will restart the wpa-daemon with the default nice value 0. So i'm back to the basic wpa-supplicant.conf version.

... my comment above lacks an 's'. Feel free to insert it before 'lowest possible 19' ;-)

This WorkAround also works for me :
- from the gnome network manager, launch the connection
- find the wpa PID by a 'ps -ef | grep wpa_supplicant'
- do a 'sudo renice 19 wpa_pid' , replace wpa_pid by the wpa_supplicant PID

Now i understand why sometimes, it can connect without this workaround, it's when i launch the connection when the PC is very busy.

--
Chri

Thanks guys, that worked for me as well!
I canged the file /etc/network/interfaces
............
pre-up nice -n 19 wpa_supplicant ...
............

and restarted the network: sudo /etc/init.d/networking restart

On Tue, Aug 12, 2008 at 1:27 PM, Chri <email address hidden> wrote:
> This WorkAround also works for me :
> - from the gnome network manager, launch the connection
> - find the wpa PID by a 'ps -ef | grep wpa_supplicant'
> - do a 'sudo renice 19 wpa_pid' , replace wpa_pid by the wpa_supplicant PID
>
> Now i understand why sometimes, it can connect without this workaround,
> it's when i launch the connection when the PC is very busy.
>
> --
> Chri
>
> --
> [ndiswrapper] [wg511] fails to associate
> https://bugs.launchpad.net/bugs/207446
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "linux" source package in Ubuntu: New
> Status in "wpasupplicant" source package in Ubuntu: Confirmed
>
> Bug description:
> Binary package hint: wpasupplicant
>
> After upgrading from gutsy to hardy, wpa_supplicant can no longer authenticate. It seems to try repeatedly until I kill it.
>
> The results of sudo wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf -dd are in the attachment.
>
> I can get a wireless connection if I disable WPA; wpa_supplicant still works fine if I boot with kernel 2.6.22.
>
> wpasupplicant version is 0.6.0+0.5.8-0ubuntu2.
>
> Wireless is netgear wg511v2/ndiswrapper.
>
> /etc/wpa_supplicant.conf is
>
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=0
> ap_scan=2
>
> network={
> ssid="MySSID"
> scan_ssid=1
> proto=WPA
> key_mgmt=WPA-PSK
> pairwise=TKIP
> group=TKIP
> psk=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> }
>

nice worked for me too. Thanks!

A bit OFFTOPIC and only of interest, if you're using WICD:
The line where wpa_supplicant is restarted is found in /opt/wicd/networking.py
and looks like:

misc.Run("wpa_supplicant -B -i " + self.wireless_interface + " -c \"encryption/configurations/" + network["bssid"].replace(":","").lower() + "\" -D " + self.wpa_driver)

You only have to prepend it with 'nice -n 19' so it reads:

misc.Run("nice -n 19 wpa_supplicant -B -i " + self.wireless_interface + " -c \"encryption/configurations/" + network["bssid"].replace(":","").lower() + "\" -D " + self.wpa_driver)

Unfortunately, not to me.

My original /etc/network/interfaces is as follows:

"
auto lo
iface lo inet loopback
"

With the proposed fix, changed to:

"
auto lo
iface lo inet loopback
pre-up nice -19 wpa_supplicant -B -i wlan0 -c "/etc/wpa_supplicant/wpa_supplicant.conf" -D wext
"

The file "wpa_supplicant.conf is not existant on my entire system.

Any help is greatly appreciated.
Thanks.

I, too, can confirm that this workaround works. Thanks all!

cirobr,
You need to remove or disable Network Manager and use manual setup via a 'wpa_supplicant.conf' configuration file in order for the /etc/network/interfaces mod to work. There are detailed How-To's and User Guides on the use of WPA_Supplicant on the Ubuntu website. Otherwise, with Network Manager running, you would need to execute the two command lines Chri provided above each and every time Ubuntu starts up and you want to establish a WPA wireless connection. HTH...

Hi !
Chri's workaround worked for me too.
Thank you.

If you want to do what the two commands do with only one, just do in your favorite terminal:
sudo renice 19 `pgrep wpa_`

I'm unsure as to what I should type following these instructions:

 Chri wrote on 2008-08-12: (permalink)

This WorkAround also works for me :
- from the gnome network manager, launch the connection
- find the wpa PID by a 'ps -ef | grep wpa_supplicant'
- do a 'sudo renice 19 wpa_pid' , replace wpa_pid by the wpa_supplicant PID

I have done the following:

ken@ken-linux:~$ sudo ps -ef | grep wpa_supplicant
root 8505 1 0 16:36 ? 00:00:00 /sbin/wpa_supplicant -g /var/run/wpa_supplicant-global
ken 8614 8581 0 16:42 pts/0 00:00:00 grep wpa_supplicant

Hi Ken,

If you want, you can only type this command line:
sudo renice 19 `pgrep wpa_`
As I tried to explain, it applies Chri's workaround in only one command line.

damdam76 wrote:
> Hi Ken,
>
> If you want, you can only type this command line:
> sudo renice 19 `pgrep wpa_`
> As I tried to explain, it applies Chri's workaround in only one command line.
>
>
As I indicated when I tried Chri's work around I initially got a
response of 'Bad data' . I did try your command line and did not see
any response indicating I had accomplished anything.

However I later discovered I now connect. I always like to know how
things work. I have a friend who had exactly the same response and he
gave up. I ended up with his PCI wireless card.

Whatever the cause I now have connectivity and I thank both you and Chri
for your sharing your skills.

Thank you.

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Hello,

I've updated from the internet my clean/original Ubuntu Hardy installation today and have noticed that problem is now fixed! Network manager is up and running as well. This update forced me to restart the machine.

Command "uname -r" on terminal gives "2.6.24-19-generic" in return.

System is running smoothly.

Anyway, many thanks!

Me again,

Back to the beginning, system is no longer accessing WPA networks no matter what I do.

Hello all

To cirobr : If "uname-r" gives "2.6.24-19-generic", it means that you don't run the 2.6.27 kernel.

May I suggest you to try the following procedure :

- reboot the machine
- when Grub takes hand, press the escape key to bring up the boot menu (you've got only 2 sec. by default to do it)
- select the line "Ubuntu, kernel 2.6.27..." (don't select "recovery mode")
- after the boot, check that "uname -r" reports 2.6.27 kernel
- check your WPA connection

Hello,

Installed kernel 2.6.27-2-generic. Same WPA-password loop, even after reinstalling Network Manager as well.

Hi,

Here a some good news !
I've installed ( and I am actually using ) kernel 2.6.27-2-generic tonight.
It took me some time to find how to achieve it, but I am happy to tell you that my Wifi dongle using ndiswrapper works like a charm, no need to renice the wpa_supplicant !
It took some little time to connect but I'm using my WPA protected wifi access right now and everything's alright.
So maybe this bug will be corrected with Intrepid 8.10.
Great.

Hope my test will help.

Bye.

Michael Lauer, since you are the original bug reporter would you be able to test 2.6.27 and confirm or deny this is resolved. We seem to have conflicting feedback. Thanks.

Kernel 2.6.27-2 behaved exactly like 2.6.24-19 (as far as this bug is concerned): WPA works with nice, not without it. :-(

Hello,

The "pre-up nice -19.........." fix works for me.

Hi! I have the same problem with wpasuplicant and ndiswrapper. Renice often works, but not every time and it is uncomfortable with Networkmanager. So I searched in the source.

My conclusion: After the last handshake packet from the access point has arrived, the computer sends its last packet and than sets the wpa key. But at this time sending of the last handshake packet is still in progress and setting the key disturbs this process. Inserting a pause between this two actions solves the problem.

wpa.c:

 void wpa_supplicant_process_3_of_4(..)
 {
  .
  .
  wpa_supplicant_send_4_of_4()
   -> wpa_eapol_key_send()
    -> wpa_sm_ether_send()
     -> wpa_ether_send()
      -> l2_packet_send()
       -> sendto()
  .
  .
  usleep(10);
  .
  .
  wpa_supplicant_install_ptk()
   -> wpa_sm_set_key()
    -> wpa_driver_wext_set_key()
     -> ioctl()
  .
  .
 }

this sounds right. I've swapped out my wireless card now so don't need to
use ndiswrapper but when i was using it it seemed (by looking at the icon in
the tray) that it would connect then get bumped off immediately... it still
seems to happen occaisionally even without using ndiswrapper. should this
be added to the next release of Ubuntu??

2008/9/20 Christof <email address hidden>

> Hi! I have the same problem with wpasuplicant and ndiswrapper. Renice
> often works, but not every time and it is uncomfortable with
> Networkmanager. So I searched in the source.
>
> My conclusion: After the last handshake packet from the access point
> has arrived, the computer sends its last packet and than sets the wpa
> key. But at this time sending of the last handshake packet is still in
> progress and setting the key disturbs this process. Inserting a pause
> between this two actions solves the problem.
>
> wpa.c:
>
> void wpa_supplicant_process_3_of_4(..)
> {
> .
> .
> wpa_supplicant_send_4_of_4()
> -> wpa_eapol_key_send()
> -> wpa_sm_ether_send()
> -> wpa_ether_send()
> -> l2_packet_send()
> -> sendto()
> .
> .
> usleep(10);
> .
> .
> wpa_supplicant_install_ptk()
> -> wpa_sm_set_key()
> -> wpa_driver_wext_set_key()
> -> ioctl()
> .
> .
> }
>
> --
> [ndiswrapper] [wg511] fails to associate
> https://bugs.launchpad.net/bugs/207446
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "linux" source package in Ubuntu: Triaged
> Status in "wpasupplicant" source package in Ubuntu: Confirmed
> Status in "wpasupplicant" source package in Debian: Confirmed
>
> Bug description:
> Binary package hint: wpasupplicant
>
> After upgrading from gutsy to hardy, wpa_supplicant can no longer
> authenticate. It seems to try repeatedly until I kill it.
>
> The results of sudo wpa_supplicant -Dwext -iwlan0
> -c/etc/wpa_supplicant.conf -dd are in the attachment.
>
> I can get a wireless connection if I disable WPA; wpa_supplicant still
> works fine if I boot with kernel 2.6.22.
>
> wpasupplicant version is 0.6.0+0.5.8-0ubuntu2.
>
> Wireless is netgear wg511v2/ndiswrapper.
>
> /etc/wpa_supplicant.conf is
>
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=0
> ap_scan=2
>
> network={
> ssid="MySSID"
> scan_ssid=1
> proto=WPA
> key_mgmt=WPA-PSK
> pairwise=TKIP
> group=TKIP
> psk=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> }
>

Hello,

Any light at the end of the tunnel so that we get back on using Network Manager?

By the way, "pre-up nice" fix still working fine.

Thanks,

Ciro.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

I'm havin the same problem:IPN2220 with ndiswrapper.

In my case this is on an older Acer Aspire 1360 which I want to give to a family member.
Installed Intrepid, then ndiswrapper + drivers from Acer Support.
The result was I could see the wireless networks, but not to WPA2 encrypted ones.
I also tried 7.10, and even with wicd, but nothing helped.

As this was kind of a deal-breaker, I ended up installing winXP again after 2 days of tweaking. But after installing all the necessary drivers from the Acer Support site, I _still_ could not logon to the protected networks, pointing towards a driver issue.

Via Windows Update, I could however update the driver and I was logged on in no time :-).
Unfortunately, I do not have the time anymore to reinstall ubuntu again, but I have a feeling these new drivers could also solve the WPA2 problem under Ubuntu.

For people who are in a similar situation and used the original Acer drivers together with ndiswrapper:
- the Acer driver (2.10.03.2004) which did not work with WPA2
  @ ftp://ftp.work.acer-euro.com/notebook/aspire_1360/driver/Acer%20IPN2220%20Wireless%20LAN%20Card%20NDIS%20Miniport%20Driver%202.10.03.2004.zip

- a newer driver (3.07.02.2005) that does work with WPA2 (at least on WinXP)
  @ http://www.laptopvideo2go.com/forum/index.php?s=4272d582eddeb21b6bdcd541dba82e09&showtopic=7172&pid=101436&st=0

HI! It seems nobody has tried my solution. It's not so easy to patch the source code. So here is a little recipe .

sudo apt-get install quilt libpcsclite-dev build-essential libssl-dev libdbus-1-dev
# maybe you need to install also other packages

mkdir wpa ; cd wpa/
pool=http://ftp.ubuntu.com/ubuntu/pool/
wget $pool/main/w/wpasupplicant/wpasupplicant_0.6.4.orig.tar.gz
wget $pool/main/w/wpasupplicant/wpasupplicant_0.6.4-2.diff.gz
wget $pool/main/w/wpasupplicant/wpasupplicant_0.6.4-2.dsc
dpkg-source -x wpasupplicant_0.6.4-2.dsc
cd wpasupplicant-0.6.4/

patch ./src/rsn_supp/wpa.c <<EOF
987a988
> usleep(10); // pause needed - because sending is in progress?
EOF

dpkg-buildpackage -us -uc -rfakeroot -d
# failing on building the wpa_gui is okay

strip wpa_supplicant/wpa_supplicant

sudo mv /sbin/wpa_supplicant /sbin/wpa_supplicant.orig
sudo cp wpa_supplicant/wpa_supplicant /sbin/
# reboot

Christof,

Thank you for your suggestion and recipe. I've been having this problem with a Dell Laptop D610 using the mini-PCI Broadcom NetXtreme BCM5751 with ndiswrapper and the XP driver bcmwl15.

I tried to rebuild wpa_supplicant as you indicated. It didn't work with the pause you recommended, but increasing it to 100000 (0.1 sec) made it work flawlessly. The patch that worked for me was, therefore:

patch ./src/rsn_supp/wpa.c <<EOF
987a988
> usleep(10); // pause needed - because sending is in progress?
EOF

PS. In my system, I also had to install package debhelper.

Correction to my previous post - here is the patch that worked:

patch ./src/rsn_supp/wpa.c <<EOF
987a988
> usleep(100000); // pause needed - because sending is in progress?
EOF

Confirmed the above patch also fixes this issue in Intrepid on the IPN2220 card under ndiswrapper. Many thanks! Will a fix be released for Intrepid and Hardy at all?

I also recompiled the wpa_supplicant recently in the way described by Christof and gersonvb and the patch worked out of the box. You should submit it in order to integrate the fix into the wpa_supplicant source code. Seems like old kernel version have been more forgiving about this bug? Greetings and thanks for the effort.

The proposed patch seems to fix also problems with Broadcom bcm4306 rev 2 not associating to AP.

Just tried on an Dell X300. Ndiswrapper had problems since at least Hardy, connecting only after many trials. In Jaunty not working at all (forced to use b43legacy). Now it is OK!

With wpa_supplicant-0.6.6:
Added usleep(100) at line 997 in wpa.c

Here is another workaround for those who don't want to recompile. In jaunty go to /etc/wpa_supplicant/functions.sh line 275 and add --nicelevel 19 to the end of line just before the backslash \.

Also confirming the above patch works, Ubuntu Karmic, Dell Inspiron 1525, BCM4312 802.11b/g (rev 01)

Also confirming for Linux Mint 7 and Ubuntu 9.10 on Dell Latitude C800 with D-Link DWL-G650+

Hi, confirming for kubuntu 9.10 (wpa_supplicant 0.6.4-2) with a netgear WG511v2 (ndiswrapper Marvell 88w8335) PC card in a dell inspiron 1100 connecting to a WPA2 AP.

Without the usleep - it connected very rarely. With the usleep (used 100000us), works every time!

The same for me: without the 'usleep' patch I can't connect to WPA2 AP at all. With the usleep (used 100000us), it works every time.
Ubuntu 9.10 (Karmic), wpasupplicant_0.6.9-3ubuntu1. Card: TL-WN821N (Atheros Otus chip, ID 0cf3:9170), ndiswrapper 1.54-2ubuntu1 uses windows driver for Netgear WNDA3100 (http://ubuntuforums.org/showthread.php?t=885520 ).

Patch position slightly differs, so here is the context diff:

*** wpa.c.ORIGINAL 2010-01-09 17:23:12.000000000 +0300
--- wpa.c 2010-01-09 23:52:26.000000000 +0300
***************
*** 993,998 ****
--- 993,999 ----
   if (wpa_supplicant_send_4_of_4(sm, sm->bssid, key, ver, key_info,
             NULL, 0, &sm->ptk))
    return;
+ usleep(100000); // pause needed, because sending is in progress

   /* SNonce was successfully used in msg 3/4, so mark it to be renewed
    * for the next 4-Way Handshake. If msg 3 is received again, the old

Hello,

The usleep(100000) modification works for me too with a DLink DWL-G650 (AR5112 chipset) card with WPA and ndiswrapper.

Thank you.

Guillaume

I have the same problem- ndiswrapper doesn't work with wpa with my ralnik 2500.
usleep patch doesn't help.
But wpa (with the same wpa_supplicant configuration) work OK with rt2500pci driver (although this driver has speed problems).
I guess this is ndsiwrapper problem...

Michael Lauer, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Closing this bug with Won't fix as Hardy is no longer supported.
Please feel free to open a new bug report if you're still experiencing this on a newer release (Bionic 18.04.3 / Disco 19.04)
Thanks!