[Intrepid] iwl3945 + iwlagn -- network-manager will not connect to a WPA EAP (Enterprise) network (disassociating by local choice (reason=3) )

Can confirm this with two different WPA-networks at my university. Similar hardware, worked under Gutsy for me (I skipped Hardy so fast that I did not get to try). Works with wicd under Intrepid.

please restart your system in range of that network. reproduce the connect failure twice, and attach the complete syslog taken afterwards.

Same problem, Intel 3945ABG hardware. Work perfectly under 8.04.1

Here is the requested file.

Same here,
up-to-date Intrepid,
with /etc/ssl/certs/class3.pem.
Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05)

Is a duplicate of Bug #264881 ???

I also have trouble connecting to the Enterprise WPA network (PEAP MS-CHAP v2) at my University.
It's really rather hit and miss if the network connects or not. Sometimes it tales several attempts at entering in the auth details before I can get it to connect generally associated with lots of 'NetworkManager: <info> wlan0: link timed out.' in the syslog. (Once connected it works quite happily. I'm using it for a connection now)

I'm using a Intel Wireless WiFi Link 4965AGN with the iwlagn driver. I was having the same issue with NM from the Hardy NM 0.7 PPA using the iwl4965 driver in Hardy. Had wondered if it was either the older driver or using NM 0.7 on Hardy. Unfortunately the problem does persist. I'm planning to try using just wpasupplicant without NM to see if I can get that to associate (and thus see if it's a NM related issue)

And conveniently it just happened to me as I went to the next building. This is just after waking the laptop up from suspend and letting it try and auto-connect. First time failed. Only had to enter in the authentication once this time to get it working. Attached is the syslog from the attempt showing both a unsuccessful and successful connection.

I'm having the same (or similar) problem.

After upgrading from 8.04 to Intrepid beta, I can not connect to my campus wireless network (WPA enterprise EAP-TLS) using network manager. The connection always fails. Before the upgrade, this worked flawlessly.

I can connect if I use wpa_supplicant from the command line, but only if I stop network-manager first (/etc/init.d/NetworkManager stop).

Also, network manager works fine on my home wireless network (WPA-PSK).

I'm attaching a portion of my syslog (beginning when I start network manager, and including a failed attempt to connect). My wireless card is an Intel 3945ABG.

I am also having trouble. For the sake of other user's searching, this is at University of Illinois (uiuc), trying to connect to UIWpa2.

Running up-to-date Intrepid beta. I'll try to get some logs up later.

Same problem here. Attached you will find the portion of syslog regarding network manager

NIC: 0c:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
Uname: Linux callisto 2.6.27-5-generic #1 SMP Fri Oct 3 00:36:38 UTC 2008 x86_64 GNU/Linux
System version: Ubuntu 8.10 Beta

Same problem here since upgrading to intrepid (over a month). Attached a chunk of syslog.

NIC: 0b:02.0 Network controller: Intel Corporation PRO/Wireless 2915ABG Network Connection (rev 05)
Uname: Linux euler 2.6.27-4-generic #1 SMP Wed Sep 24 01:30:51 UTC 2008 i686 GNU/Linux

Ding ding ding.

Works flawlessly if I use wpa_supplicant, not so much if I try network-mangler.
Network-mangler 0.7~~svn20080928t225540+eni0-0ubuntu2
NIC: 03:00.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01)
Uname: Linux eris 2.6.27-4-generic #1 SMP Wed Sep 24 01:29:06 UTC 2008 x86_64 GNU/Linux

I'm going to go compile 0.6 and see what I get.

could you please try to load your iwl3945 or iwl4965 driver with disable_hw_scan=1 like:

 modprobe -v -r iwl3945
 modprobe -v iwl3945 disable_hw_scan=1

or

 modprobe -v -r iwl4965
 modprobe -v iwl4965 disable_hw_scan=1

Should this generalize to ipw2200 drivers as well?

No change for me loading modprobe -v iwl3945 disable_hw_scan=1.

doing the modprobe -v... didn't have any effect either.

I think this bug was inappropriately changed to iwl3945 + iwl4965. This is affecting ipw2200 users and I tried it on an atheros card earlier with similar results.

It affects at least iwl4965 since this is my case!

I tried reloading the iwl3945 using the disable_hw_scan=1 option:

 modprobe -v -r iwl3945
 modprobe -v iwl3945 disable_hw_scan=1

This didn't help at all.

Also, I don't think this bug has any specific relation to the Intel wireless card (iwl3945/iwl4965): I have reproduced the bug using a USB wireless interface (Zydas 1211 chipset). I set the kill switch for the built in Intel card, and plugged in my USB card; syslog showed Network Manager failing with the same errors: link time out, association took too long, disassociating by local choice (reason=3), etc.

Both devices work fine if I kill NetworkManager and run wpa_supplication manually.

I'm attaching syslog excerpts for failed connections when using both devices.

Also affects prism54 chipsets too.

I have attempted to downgrade several packages to hardy level including network-manager, network-manager-gnome, dhcdbd, libnm, wpa-supplicant etc., but all have exhibited the same behaviour of attempting to connect, and then doing the local disconnect=3 message

Problems with 2.6.27 kernels.
And not only iwl2945, tested with a usb zd1211 chip (3com)

I've tested with 2.6.24-19 and it's working well.

Now I'm testing with 2.6.22-14 and iwl3945 is not working, same behavior as 2.6.27-6 (today's updates). BUT zd1211 is Working like a charm.

I don't know how else can aport to debug. I'll atach my 2.6.22-14 dmesg for debugging pourposes.

Reloading the module did not help me at all.
This problem is getting more and more annoying...

This is looking more like an NM issue, however I don't have an AP capable of WPA Enterprise in order to conclusively prove it.

I did get connected with Tunnel TLS instead of PEAP, which the NOC group on my campus told me should not be compatible with there system

I would like to tell that the todays update of NetworkManager did not solve the issue. Same problem, same logs!

http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1629

the user there reports it without using NM at all. reopening linux task, adding wpasupplicant task until we know whats going on.

not in progress for NM until we know what causes this.

I'm here to give any additional information that might be useful, just ask.

In my opinion, it looks like something more related to the kernel or driver rather than NM.

On my system this is clearly a Network Manger bug, not a kernel/driver bug.

I have two kernels installed, 2.6.24-21-generic and 2.6.27-4-generic. When I boot the older 2.6.24 kernel I cannot connect using Network Manger, but I connect right away using wpa_supplicant from the command line. When I boot the newer 2.6.27 kernel, I am also unable to connect using Network Manger, but once again wpa_supplicant connects right away from the command line.

I am attaching four files showing syslog during attempts to connect using NM and wpa_supplicant on the 2.6.24 kernel, and attempts to connect using NM and wpa_supplicant on the 2.6.27 kernel.

could you also please attach a tail on /var/log/wpa_supplicant.log?

This is happening for me too with ndsiwrapper and BCM4328. It worked great yesterday (October 15) and after aptitide dist-upgrade it won't work at all today. WPA Personal networks work perfectly. I can't connect using wpa_supplicant alone either.

I got new output from wpa_supplicant after rebooting to use the new wl driver instead of ndiswrapper. The logging in daemon.log is the same, and the wpa_supplicant logging is the same after reverting back to ndiswrapper.

I'm attaching two pieces of wpa_supplicant.log. Both are from connection attempts using Network manager. The first log file seems to show two errors:

TLS: Certificate verification failed, error 19 (self signed certificate in certificate chain) depth 2 for '/DC=edu/DC=marshall/CN=Marshall University Root CA'
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA

SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA
OpenSSL: tls_connection_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

The first error looks like a red herring: I removed the CA cert from the nm-applet configuration, and tried again, but the connection still failed with:

OpenSSL: tls_connection_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Oh I forgot to mention -- if you are required to provide a certificate, it must be an *.pem file in /etc/ssl/certs. Make sure you update your certificate cache (see directions earlier in this thread.)

Dan

Following posted directions for Windows (http://www.it.northwestern.edu/oncampus/wireless/wireless-connections/wireless-win.html), wireless is 802.1x/WPA2, PEAP, MSCHAPv2. I figured out PEAPv0 while getting wpa_supplicant to work under Puppy Linux (it worked flawlessly, but on a different laptop, so the driver and networking hardware may be an issue). I've never had to deal with certificates in Ubuntu at the times when the connection worked. When it doesn't work, I am presented with the dialog box asking for a certificate. I don't believe I'm supposed to need a certificate. Under Windows, the procedure is that I am asked to authenticate myself with a password and then I'm connected. (Actually, even Windows sometimes has trouble connecting. I have found Lenovo's Access Connections to work reliably as does wpa_supplicant in Puppy Linux.)

I'm not a networking guru and I'm not a Ubuntu expert so I may miss something. The important thing from my perspective is that some of the time the wireless connection just works, and it works for hours, and it reconnects if I click on the GUI. Other times it will not connect no matter what I try.

It would help if you attached your /var/log/wpa_supplicant.log file to this bug report. Try and get connected a few times and then also see if you can get a few failures in there. If you have intermittent connections -- it really sounds like a driver thing (or a thing on northwestern's end.)

From the link you posted, it doesnt look like you need a cert. It might be worth trying PEAPv1 -- just to see if it works.

Dan

Network-manager still does not connect. With a connection set up as described above (wpa2, peapv0, mschapv2) I still get the dialog box asking if I want to select a certificate, followed by no connection. The log (/var/log/wpa_supplicant.log) contains an endless string of the following:

CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys

etc.

However, I am now able to connect using wpa_supplicant. I run this on the command line:

sudo wpa_supplicant -c wpa_supplicant_nu.conf -d -iwlan0 -Dwext -B

once it connects I run dhclient3

Here is the config file wpa_supplicant_nu.conf

ctrl_interface=/var/run/wpa_supplicant
update_config=1

network={
 ssid="Northwestern"
 scan_ssid=1
 proto=WPA2
 key_mgmt=WPA-EAP
 pairwise=CCMP TKIP
       group=CCMP TKIP
 eap=PEAP
 identity="myidentity"
 password="xxxxx"
 phase1="peaplabel=0"
 phase2="auth=MSCHAPV2"
}

So given this result I am guessing that this is *not* a driver problem and that there is still some error in the way that network-manager is interacting with wpa_supplicant.

It could still be a driver issue -- as you manually specified the wext driver in that command...

Out of curiosity, what version of network manager are you running? Maybe the jaunty sources got updated (and re-broken)? Get the exact version # from synaptic (should be kinda weird with some ~~ things).

Dan

NM version is 0.7~~svn20081018t105859-0ubuntu2

Good point about the driver. If I try to specify iwlagn wpa_supplicant doesn't know what that is.

One more weird thing to mention. I can use wpa_supplicant manually to connect right after rebooting. If I bring down wlan0 and then try to reconnect, it seems to work once or twice and then I can't reconnect without rebooting. Each time I am deleting /var/run/wpa_supplicant/* . I don't know networking well enough to understand what rebooting changes.

Try running wpa_supplicant again without the -D setting eg:

sudo wpa_supplicant -c wpa_supplicant_nu.conf -d -iwlan0 -B

Can you get the versions of all the packages in my initial post?

Thanks

Dan

Based on two tries -Dwext seems to be necessary.

Here are the versions from aptitude show:

wpasupplicant 0.6.6-2
libnm-glib0 0.7~~svn20081018t105859-0ubuntu2
libnm-util0 0.7~~svn20081018t105859-0ubuntu2
libxcb-render-util0 0.2.1+git1-1
network-manager 0.7~~svn20081018t105859-0ubuntu2
network-manager-gnome 0.7~~svn20081020t000444-0ubuntu2

Those packages are ok.... I'm officially out of ideas ... :-/

On Tue, Jan 13, 2009 at 7:29 PM, Dan Bracey <email address hidden> wrote:

> Those packages are ok.... I'm officially out of ideas ... :-/
>
>

Is there a way to tell network-manager to use a different wireless driver?
(Since wext seems to work, at least some of the time.)

Sure, I didnt think that about that... Try adding this line to /etc/network/interfaces:

wpa-driver wext

You need to be root to edit that file. Ex. gksudo gedit /etc/network/interfaces. You'll probably need to reboot after editing the file.

Dan

Unfortunately changing the driver isn't the answer. And despite my initial
flurry of success, wpa_supplicant on the command line isn't the answer
either. It may connect with a slightly higher probability, but most of the
time I don't connect however I try.

On Tue, Jan 13, 2009 at 10:31 PM, Dan Bracey <email address hidden> wrote:

> Sure, I didnt think that about that... Try adding this line to
> /etc/network/interfaces:
>
> wpa-driver wext
>
> You need to be root to edit that file. Ex. gksudo gedit
> /etc/network/interfaces. You'll probably need to reboot after editing
> the file.
>
> Dan
>
> --
> [Intrepid] iwl3945 + iwlagn -- network-manager will not connect to a WPA
> EAP (Enterprise) network (disassociating by local choice (reason=3) )
> https://bugs.launchpad.net/bugs/272185
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "knetworkmanager" source package in Ubuntu: Invalid
> Status in "linux" source package in Ubuntu: Invalid
> Status in "network-manager" source package in Ubuntu: Triaged
> Status in "network-manager-applet" source package in Ubuntu: Fix Released
> Status in "network-manager-openvpn" source package in Ubuntu: Triaged
> Status in "wpasupplicant" source package in Ubuntu: Triaged
> Status in knetworkmanager in Ubuntu Intrepid: New
> Status in linux in Ubuntu Intrepid: Triaged
> Status in network-manager in Ubuntu Intrepid: Triaged
> Status in network-manager-applet in Ubuntu Intrepid: Fix Released
> Status in network-manager-openvpn in Ubuntu Intrepid: Triaged
> Status in wpasupplicant in Ubuntu Intrepid: Triaged
>
> Bug description:
> Proposed fix-packages:
> https://edge.launchpad.net/~network-manager/+archive<https://edge.launchpad.net/%7Enetwork-manager/+archive>
>
> Binary package hint: network-manager
>
> I'm having troubles connecting to my campus wireless network with Intrepid
> Ibex (updated 19 Sept 2008). I have a Dell XPS m1330 laptop with ipw3945
> card. This laptop connects fine under Ubuntu 8.04.
>
> Here are the setting my campus suggests I use.
>
> SSID: uconnect.utah.edu
> Encryption: WPA Enterprise
> Encryption Type or Key: TKIP
> EAP Method: PEAP
> CA Server Certificate: Entrust.net (do not need to enter under Network
> Manager under Ubuntu 8.04)
> Authentication Method: MS-CHAP v2
> Username: *****
> Password: *****
>

Dan asked earlier for a log of a successful connection. Here are both (these are using the default driver, which I believe is iwlagn). Successful connections remain sporadic.

Successful:

CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:11:92:3e:79:80 (SSID='Northwestern' freq=2447 MHz)
Associated with 00:11:92:3e:79:80
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
EAP-MSCHAPV2: Authentication succeeded
EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
WPA: Key negotiation completed with 00:11:92:3e:79:80 [PTK=CCMP GTK=CCMP]
CTRL-EVENT-CONNECTED - Connection to 00:11:92:3e:79:80 completed (auth) [id=3 id_str=]
CTRL-EVENT-SCAN-RESULTS
WPA: Group rekeying completed with 00:11:92:3e:79:80 [GTK=CCMP]
CTRL-EVENT-SCAN-RESULTS
WPA: Group rekeying completed with 00:11:92:3e:79:80 [GTK=CCMP]
CTRL-EVENT-SCAN-RESULTS
WPA: Group rekeying completed with 00:11:92:3e:79:80 [GTK=CCMP]
CTRL-EVENT-SCAN-RESULTS
etc.

Unsuccessful:

CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:11:92:3e:79:80 (SSID='Northwestern' freq=2447 MHz)
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Authentication with 00:00:00:00:00:00 timed out.

I think I'm also affected by this bug.
I'm running Ubuntu 8.10 with all repositories enabled (means I run kernel 2.6.27-11-generic (uname -r)).
>lspci |grep 3945
02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)

At home, I can connect to my WPA Personal network.
On the university, I have a WPA2 Enterprise/TTLS/PAP authentication. Here, I often cannot connect. If, after several retries, I'm connected, the connection drops in no time: sometimes after 10 seconds, sometimes after some minutes.

I noticed that after uninstalling the package linux-backports-modules-intrepid, the connection success rate raised a little bit (so I needed less retries before I am connected). However, this is still not usable.

Ernst -- did you try my fix?

Dan

Yes, I tried installing the jaunty packages. After updating my repositories, updating and selecting the packages, Synaptic forced me to install some other (dependent) packages. However, it did not solve my problems with WPA2/TTLS/PAP; I still had trouble connecting and took a lot of tries before it was connected.

After that, I did encounter a new problem: I occasionally got a "Authentication with 00:00:00:00:00:00 timed out." message in my wpa_supplicant log, resulting in a long reconnect time to a 'regular' WPA access point. Before the Jaunty packages, I never had problems with this access point (no reconnects or whatever).

I think I solved the time-out problem by running 'sudo aptitude reinstall'. At first, it gave errors, because there was no installation candidate for some of the packages (they only exist in jaunty?). After downgrading those packages (a solution offered by aptitude after trying to remove those packages) and reinstalling all packages again, I think I restored my system to the state before the jaunty packages.

Thanks for your help! Hopefully, my report helps to solve this bug

Hey so first thing, I also tried installing the packages from the Jaunty repo that were suggested but that didn't help at all. Mine is a WPA PEAP wireless lan. I can connect instantly with wpa_supplicant but not with network manager.

my wpa_supplicant.conf looks like this (I've tried to remove everything that isn't absolutely necessary):

ctrl_interface=/var/run/wpa_supplicant
network={
 ssid="WLAN-TWDC"
 proto=WPA
 key_mgmt=WPA-EAP
 eap=PEAP
 identity="xxx"
 password="xxx"
 phase1="peaplabel=0"
# phase2="auth=MSCHAPV2"
}

I think the problem I'm seeing is pretty much exactly what Jan above described (https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/272185/comments/131). Including the phase2 line prevents me from connecting, but when I leave it out I connect pretty much instantly.

I'm attaching the wpa_supplicant output from a failed connection. It seems the problems are happening around line 389. I'll also attach a successful one just for the heck of it.

Here's a successful connection

I seem to be able to connect if, using the CLI, I issue the command "iwconfig wlan0 essid northwestern". Is it apparent to anyone why this command would help NM connect?

I'm not sure the sequence matters, but if NM fails to connect automatically, (I keep getting the certificate dialog), I click
"cancel" on the dialog and run the iwconfig command. Sometimes it then connects automatically, other times I need to click on the NM icon for the connection, after which it connects. If I issue the command before I get the certificate dialog, it just connects. So far I have had no failures with this method, but I am reluctant to claim victory. I hope that others still having problems can try this out.

My previous reports are around here:

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/272185/comments/182

Please let me know if there's something I can try to help pin down what's going on.

Here is a successful connection:

CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:15:f9:47:24:70 (SSID='Northwestern' freq=2462 MHz)
CTRL-EVENT-SCAN-RESULTS
Associated with 00:15:f9:47:24:70
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
EAP-MSCHAPV2: Authentication succeeded
EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
WPA: Key negotiation completed with 00:15:f9:47:24:70 [PTK=CCMP GTK=CCMP]
CTRL-EVENT-CONNECTED - Connection to 00:15:f9:47:24:70 completed (auth) [id=0 id_str=]
CTRL-EVENT-SCAN-RESULTS
WPA: Group rekeying completed with 00:15:f9:47:24:70 [GTK=CCMP]

hey, had the same issue that chris walkelin describes at comment #79 (see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/272185/comments/79 ) while connection to the wireless network at my university (also using eduroam)
i'm not using ubuntu, but it seems that is the same error.

using archlinux 2.6.28
first i tried to connect via network-manager 0.7, but it keeps asking for password.
checked the loaded modules for my usb-wlan-stick (linksys WUSB54GC) and it was rt73usb.

so i blacklisted that module and loaded the linksys with ndiswrapper and windows-drivers from the linksys-homepage.

--> result: works perfectly with that configuration. (connection over nm-applet takes a bit longer, but then connection is stable and fast)

maybe that information can help you solving that problem.

Thanks for the suggestion, but I'm pretty sure what I'm seeing is this
bug in Network Manager:
http://bugzilla.gnome.org/show_bug.cgi?id=565065

Uri

On Mon, Mar 2, 2009 at 4:34 AM, LHM <email address hidden> wrote:
> hey, had the same issue that chris walkelin describes at comment #79 (see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/272185/comments/79 ) while connection to the wireless network at my university (also using eduroam)
> i'm not using ubuntu, but it seems that is the same error.
>
> using archlinux 2.6.28
> first i tried to connect via network-manager 0.7, but it keeps asking for password.
> checked the loaded modules for my usb-wlan-stick (linksys WUSB54GC) and it was rt73usb.
>
> so i blacklisted that module and loaded the linksys with ndiswrapper and
> windows-drivers from the linksys-homepage.
>
> --> result: works perfectly with that configuration. (connection over
> nm-applet takes a bit longer, but then connection is stable and fast)
>
> maybe that information can help you solving that problem.
>
> --
> [Intrepid] iwl3945 + iwlagn -- network-manager will not connect to a WPA EAP (Enterprise) network (disassociating by local choice (reason=3) )
> https://bugs.launchpad.net/bugs/272185
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I'm in aup-to-date Jaunty Alpha 6 and i'm experiencing this on multiple machines (32-bit and 64-bit), across multiple networks WPA and WPA 2 personal.

Danny, have you tried my suggestion to run in a terminal "iwconfig wlan0 essid ssid_name"? (substitute for wlan0 and ssid_name as appropriate). I have no idea why this works, but I have had a 100% connection success rate over the last 6 weeks. I find it works either a) to issue the command once NM starts trying to connect, or b) to issue it after the WPA2 password dialog pops up. If (b), I sometimes have to click on the NM icon and then click on the particular connection I'm trying to make. But I have been connecting daily with no failures since I first discovered this workaround.

If a networking guru has any clue why this might work, I would love to hear an explanation.

Danny, you might also want to check out bug #347572: iwl3945 unable to connect to WPA personal without linux-backports-modules being installed

Having updated to Janty Beta this morning, things appear much improved. The connection disconnects but reconnects itself without intervention. Running NetworkManager with --no-daemon I see the following errors listed, not sure if these relate to all the disconnects but are probably at least some of them.

NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
NetworkManager: <info> (wlan0): device state change: 8 -> 3
NetworkManager: <info> (wlan0): deactivating device (reason: 0).
NetworkManager: <info> wlan0: canceled DHCP transaction, dhcp client pid 19201
NetworkManager: <info> (wlan0): removing resolv.conf from /sbin/resolvconf
-- Error received: Numerical result out of range
-- Original message: type=0x19 length=56 flags=<REQUEST,ACK> sequence-nr=1238157499 pid=4204341
NetworkManager: <WARN> check_one_route(): (wlan0) error -34 returned from rtnl_route_del(): Sucess

NetworkManager: <info> Activation (wlan0) starting connection '<ESSID>'

I don't see any similar issues if I use wpa_supplicant and dhclient directly.

What is the status on this bug? I was suffering from this problem on Intrepid for quite long time, but now using the kernel "2.6.27-11-generic" and the iwl3495 from compat wireless (http://linuxwireless.org/en/users/Download) dated of 2009-03-31 I do not have any problem.

I am now connected in my university WLAN which uses WPA2 (TTLS + PAP) using the NetworkManager.

If I reboot (sometimes a few times) or log out (also a few times) it will reconnect on my Updated Beta jaunty on my asus 1000HE.

At the moment, on Jaunty 32-bit, all repo's enabled, I can connect on every place at my university. However, after 15 minutes or so, the connection is dropped and I have to manually select the wireless network again.

Using wpa_supplicant, everything works fine.

Can anyone reproduce this using the latest Karmic? Network Manager in Karmic is substantially improved from Jaunty and earlier.

Indeed, my severe problems with connecting to WPA2-PEAP (MSChapV2) went completely away with the newer Karmic versions. (Intel 5300 WiFi card here, 32bit OS.)

I can't test anymore. I am no longer working at the company that had it.

On Mon, Oct 5, 2009 at 3:29 PM, hasi <email address hidden> wrote:

> Indeed, my severe problems with connecting to WPA2-PEAP (MSChapV2) went
> completely away with the newer Karmic versions. (Intel 5300 WiFi card
> here, 32bit OS.)
>
> --
> [Intrepid] iwl3945 + iwlagn -- network-manager will not connect to a WPA
> EAP (Enterprise) network (disassociating by local choice (reason=3) )
> https://bugs.launchpad.net/bugs/272185
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Jeffery Rash

I face this problem after upgrading to Karmic today. ATM I've no idea if it's kernel or network-manager caused, but my wifi-commection is flapping constantly and the only error I see is: "disassociating by local choice (reason=3)"
btw: I'm using a BCM4318 with the b43 driver.

This bug is not about issues with OpenVPN.

Thank you for reporting this bug to Ubuntu. Intrepid Ibex 8.10 reached EOL on 30 March 2010.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

Please feel free to report any other bugs you may find.
Thank you.

I realized I had made a mistake, Intrepid Ibex 8.10 "will reach" EOL on 30 "APRIL" 2010.

Sorry for this.

Anyway, I think that one month doesn't make any difference now.

Anyone still getting "disassociating by local choice (reason=3)" should also read bug #548992 and consider trying

    iwconfig wlan0 power off

to disable power management.