Some drivers do not work with wpasupplicant, and therefore NM.

[monkeyhelper]

Binary package hint: network-manager-gnome

When trying to connect to WEP encrypted networks the network manager cannot connect. In the syslog output it looks as if wpa_supplicant times out when trying to authenticate. It appears to be a problem in particular with the ipw2200 (intel 2200bg) drivers but could possibly affect others too. I have managed to make wpa_supplicant authenticate on the command line so it doesn't appear to be a configuration/user issue but rather the interaction between wpa_supplicant and network-manager.

More information and examples can be found at :

http://ubuntuforums.org/showthread.php?t=187571

In particular the problem seems to affect setups where 'shared key' rather than 'open key' is required.

[Anton (anton-b)]

In addition to the previous post: the acx driver is affected as well, though the solution of switching from 'shared key' to 'open key' doesn't work. It still wants to connect via wpa_supplicant.

[Patrick Tescher (pat2man)]

Same issue with the hermes driver.

[Andrew Waldram (andrew-waldram)]

And hostap

[Gustavo Niemeyer (niemeyer)]

One more case with hermes/orinoco_cs.

[Mike Basinger (mike.basinger)]

Same with a Toshiba M30 with ipw2200.

[Wouter de Vries (w-l-devries)]

same here with ipw2100 on ThinkPad R50p

[Wouter de Vries (w-l-devries)]

The problem is that even though shared is selected the security mode is set to open instead of restricted. (verifiable by running iwlist key while trying to connect)

[Maxim (maximsch2)]

And for at76c503a driver too. Please fix it.

[Guy Van Sanden (gvs)]

acx D-Link card, same here, no access to WEP encryption.

It works fine with iwconfig essid $myid key $mykey

[Tom Wood (woodts)]

Same problem with Atheros based card Netgear WG511T.

[lknfdskjy76 (cfer45ysd)]

same problem with ipw2915abg using knetworkmanager
it only works if iwconfig eth1 key restricted $wepkey

[Eddie Hung (eddieh)]

I have this problem too, with an atmel device, on Dapper. NM refuses to connect to any WEP access point, and it has already been pointed out that this is seeming a problem to do with wpa_supplicant also.

However, setting the essid and key using iwconfig (or inside /etc/network/interfaces) works.

The latest edgy build also works correctly, using exactly the same hardware.

[Eddie Hung (eddieh)]

Seems like I cannot edit my old comment.

N.B. There is a workaround for this problem (namely downgrading to version 0.5.x) described in the wiki: https://help.ubuntu.com/community/WifiDocs/NetworkManager

[Scott Robinson (scott-ubuntu)]

Does this issue still occur for anyone using Edgy?

Basically, what cards don't quite work with wpasupplicant yet?

[Eddie Hung (eddieh)]

I have an atmel based 3com card, and I cannot connect to open WEP networks (opposed to shared) under edgy, much similar to https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/34752 (read my posts at the end).

However, if I connect using iwconfig, it works fine (rather than it not working whatsoever under dapper, using wpa_supplicant-NM or iwconfig).

[David Planella (dpm)]

>Does this issue still occur for anyone using Edgy?

>Basically, what cards don't quite work with wpasupplicant yet?

Yes, this still happens in Edgy. If I understood it correctly, it is a driver-related issue. On my particular case, I am using the open source acx driver shipped in ubuntu and I am affected by this bug. I can connect to a WEP network using iwconfig & co., but I cannot connect with network-manager (although n-m can scan networs and show their ESSIDs).

According to their webpage wpasupplicant has not yet been tested with this driver:

http://acx100.sourceforge.net/wiki/WPA

[Simon Ruggier (simon80)]

Ndiswrapper doesn't work with wpasupplicant, I think, but I haven't tried in
a couple of months, I just downgraded NM and let it be.

[Scott Robinson (scott-ubuntu)]

Correct, ndiswrapper doesn't work but for a reason in NM that is being fixed bug 46136.

[Simon Ruggier (simon80)]

The "fix" in NM in that bug is to use wireless extensions instead of wpasupplicant with ndiswrapper, in effect confirming what I just said. Bug 42504 seems to be about ndiswrapper not working with wpasupplicant, at a glance.

[Scott Robinson (scott-ubuntu)]

Bug 42504 and 46136 are the same bug. (but not marked as duplicate for historical / versioning reasons) Since you keep making casual reads as opposed to understand the problem, let me describe it here in detail to resolve your curiousity:

In dapper, the version of ndiswrapper is only partially compatible with wpasupplicant. Therefore, only _some_ ndiswrapper setups work well with the ndiswrapper-specific wpasupplicant work-around that is actually selected by NM. The remaining setups continue breaking. Therefore, using ndiswrapper with NM (and wpasupplicant) in dapper is a inconsistent situation and a lot of people solved the issue by either rolling back, or reverting the workaround.

In edgy, the version of ndiswrapper is much newer. It is fully compatible with wpasupplicant running in its normal mode of using wireless extensions. However, the dapper workaround patch to NM that calls wpasupplicant with the alternate driver is still in the package. Therefore, out of the box, NM (not wpasupplicant) is broken on edgy with ndiswrapper. wpasupplicant works fine, but NM is instructing it to run in a historical method.

Perhaps that helps explains the issue? This bug is, of course, totally different than the ones occurring in this bug. In this situation, the drivers themselves simply do not work with wpasupplicant in wireless extensions mode at all.

My plain is to start a hardware database on the wiki for working NetworkManager configurations once the ndiswrapper patch removal is approved by main sponsors. (Thereby being able to close out several bugs.)

[Simon Ruggier (simon80)]

Thanks, that explanation greatly clarifies the issue - not knowing
much about wpasupplicant, I assumed that reverting to wireless
extensions meant doing away with wpasupplicant altogether, and spoke
too soon.

[Chris Wagner (chris-wagner)]

Scott Robinson: Have you created that wiki page for working NetworkManager configurations yet? Thanks.

[Alan (stalefries)]

me too, orinoco_cs. I'll try downgrading wpa_supplicant.

[Alan (stalefries)]

I had the wpasupplicant from Trevino's repos installed, and after downgrading to 0.5.4-5, WEP encryption now works. Trevino's repos had version 0.5.7+3v1ubuntu5 (http://3v1n0.tuxfamily.org/dists/edgy/3v1n0/index.html). Perhaps some update between those two caused this?

[Michael B. Trausch (mtrausch)]

The rt74 driver, which is required for adequate functioning with my adapter, also fails to work with NetworkManager due to this issue. (My problem's history is in bug 104382, which I just found the rt74 driver as a workaround for.) I am using Ubuntu Feisty.

[Nick Moffitt (nick-moffitt)]

I believe that I have observed this bug on several similar systems. Feisty is unable to connect to a WPA network (appearing to timeout/blacklist as described) on a variety of thinkpads that I have encountered on the same wireless network.

These laptops have the following wireless network devices (most are the 2200BG rev05):

04:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05)
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

My observations are based solely on one particular WPA network, and I cannot say whether or not these devices work on other secured wireless networks (though my own 2200BG has little trouble connecting to unsecured wireless networks aside from bug#83178)

[Nick Moffitt (nick-moffitt)]

One little addendum to my previous entry. I'm not sure if it is relevant, but I believe that all of these systems were upgraded from Edgy. My own system switched to feisty shortly before the Beta release, and was in fact able to connect to WPA networks on several occasions in mid-to-late March. I am afraid I cannot tell what exact dates or revisions of network-manager that corresponds to, but I suspect that this has something to do with the downgrade workaround I see posted here.

[Steve Alexander (stevea)]

As commented in bug 53788 (a duplicate of this one), I'm seeing a related problem with a Sitecom WL-171 (RaLink RT2561/RT61), and NetworkManager Applet 0.6.4.

I can use the wireless network just fine if I connect using dhclient ra0. However, I can't get network manager to actually connect, even if I run dhclient while it is trying to connect.

The wireless network is completely open, so no WPA.

[Nick Moffitt (nick-moffitt)]

Please disregard my previous comments. It turns out that there was a miscommunication about the spelling of the WPA password, and I was trying the wrong one on all of the systems I listed above. The feedback for this failure was lacking, so I assumed it was a NM bug. I am now successfully connected to the WPA access points using the hardware I listed above.

[Kourosism (kourosism)]

I am getting a possibly related issue with my Advent 7113 laptop, which has an inbuilt MSI 6877 WLAN. It can see the network just fine, but cannot connect - this is true for WPA authentication as well as WEP and open networks, although other users have suggested they have succeeded by using WPA on their own similar machines.

[Alexander Sack (asac)]

Can you please test if this is still an issue for you with latest gutsy live cd?

[Alexander Sack (asac)]

this bug is far too generic. Please open a new bug for your specific driver if you still see issues.

[Steve Alexander (stevea)]

This bug has three duplicates, each of which is for a specific card. So, those bugs were marked duplicates of this one... and now you've marked this bug invalid because it is not specific enough. That seems kind of inconsistent, if you see what I mean.