rt2500 driver does not implement wireless extensions correctly

[Andrew Jorgensen]

Using version 0.4.8-0ubuntu2 on dapper with network-manager 0.6.1 (from main). I cannot connect to any wireless networks (unencrypted even) because wpasupplicant claims that it cannot associate with the AP. This claim is false because it does, in fact, associate with the AP. Here is an example of the log output:

Starting AP scan (broadcast SSID)
Scan timeout - try to get results
 of scan results (2 BSSes)
Scan results: 2
Selecting BSS from priority group 0
0: 00:13:10:35:e4:23 ssid='Jorgensen' wpa_ie_len=0 rsn_ie_len=0 caps=0x1
   skip - no WPA/RSN IE
1: 00:14:bf:03:0c:a5 ssid='' wpa_ie_len=0 rsn_ie_len=0 caps=0x1
   skip - no WPA/RSN IE
   selected non-WPA AP 00:13:10:35:e4:23 ssid='Jorgensen'
Trying to associate with 00:13:10:35:e4:23 (SSID='Jorgensen' freq=0 MHz)
CTRL_IFACE monitor send - hexdump(len=42): 2f 76 61 72 2f 72 75 6e 2f 4e 65 74 77 6f 72 6b 4d 61 6e 61 67 65 72 2f 77 70 61 5f 63 74 72 6c 5f 33 39 37 39 2d 31 00 00 00
Cancelling scan request
WPA: clearing own WPA/RSN IE
Automatic auth_alg selection: 0x1
WPA: clearing AP WPA IE
WPA: clearing AP RSN IE
WPA: clearing own WPA/RSN IE
No keys have been configured - skip key clearing
wpa_driver_wext_set_drop_unencrypted
State: SCANNING -> ASSOCIATING
wpa_driver_wext_associate
Association request to the driver failed

[Reinhard Tartler (siretart)]

To be honest, I suspect this to be a bug in network-manager rather than wpasupplicant. Could you please try to configure your network in /etc/network/interfaces as described in /usr/share/doc/wpasupplicant/README.modes? Please attach (not paste) your /etc/network/interfaces plus debug logs.

you can generate the debug log of wpasupplicant using `sudo wpa_cli`, and issuing the command 'level 0' at first.

the debug log of ifup can be created by issuing 'sudo ifup --verbose ra0' (or whatever your interface is)

[Andrew Jorgensen (ajorg)]

Sadly it looks like rt2500 doesn't support the newer version of the wireless extensions. There were a bunch of ioctl not supported messages. Even more sadly the maintainer is working on a new driver (that does support the new extensions) and won't be doing any work on the older driver.

[sam tygier (samtygier)]

also seeing this. is it possible to use networkmanager without wpasupplicant?

[sam tygier (samtygier)]

after Andrew Jorgensen it seems that info is not needed.

[Reinhard Tartler (siretart)]

reassigning to the correct package. If the driver doesn't support WPA properly, there is nothing that we can do about that in wpasupplicant

[Andrew Jorgensen (ajorg)]

It's not that it doesn't support WPA, it's that it doesn't support the wireless extensions used by wpasupplicant's wext driver. A wpasupplicant driver could be written to support the ioctls that rt2500 does use.

Another possibility is that wpasupplicant could be fixed to recognize what level of extensions are supported and fall back to only controlling the ssid. Or better yet, network-manager could recognize the problem and fall back to controlling the device directly.

In some reasonable way I'd love to see this fixed. I used to be able to use network-manager and now I can't (there's a bug elsewhere about network-manager not actually working without wpasupplicant like it claims it can).

In a later release, possibly dapper+1, we should be able to replace the rt2500 driver with the rt2x00 driver which does support the latest extensions. I can't test that driver right now because it requires kernel 2.6.16.

[sam tygier (samtygier)]

i am pretty sure that network manager 0.5 did not use wpasupplicant.

[Reinhard Tartler (siretart)]

wpasupplicant indeed had a driver backend for rt2500 based cards, but this backend never really worked and was therefore disabled in the package. You can try to recompile wpasupplicant with that support, but don't hope too much.

The only real solution at this point seems to me to either make rt2500 provide the needed extensions or to switch to rt2x00, which is a dapper+1 think. IOW: I don't see wpa support for rt2500 based cards in dapper. Sorry.

[sam tygier (samtygier)]

this will also mean no network-manager for rt2500 in dapper, as NM is using wpasupplicant as a back end now.

[ingbraun (ingbert-braun-deactivatedaccount)]

I have a similar problem with wpasupplicant in Flight 6. I use wpasupplicant with ndiswrapper driver (for DWL-510) and it worked with the same configuration in breezy (and fedora core 5), but on dapper its broken. On the debug output I get the same error as above for my ap/ssid:
   skip - no WPA/RSN IE
Ndiswrapper sais hardware present and working and wpasupplicant can also detect ssids in the area, but can not associate to ap. Can anyone help?

[Reinhard Tartler (siretart)]

> skip - no WPA/RSN IE
usually this means that wpasupplicant has detected that the AP in
question does not provide WPA
>

[ingbraun (ingbert-braun-deactivatedaccount)]

>usually this means that wpasupplicant has detected that the AP in question does not provide WPA

In fact, it does provide WPA. As I wrote, the same ap with the same wpa_supplicant.conf works fine with breezy and Fedora...

[Ben Collins (ben-collins)]

The issue to me seems to be that wpasupplicant left rt2500 behind. If it worked in breezy, then it should continue to work in dapper. Considering that the regression occured because of wpasupplicant upgrade losing support for rt2500, then I think the blame lies there.

[Andrew Jorgensen (ajorg)]

I'm sorry, Ben, we should have been more clear. It's not wpasupplicant that left rt2500 behind it's network-manager (by requiring wpasupplicant).

[Ben Collins (ben-collins)]

Sorry about that.

[sam tygier (samtygier)]

as a work around install the old network-manager before it started using wpasupplicant

get the network-manager package
https://launchpad.net/distros/ubuntu/dapper/powerpc/network-manager/0.5.1-0ubuntu19
https://launchpad.net/distros/ubuntu/dapper/i386/network-manager/0.5.1-0ubuntu19
and nm-applet
https://launchpad.net/distros/ubuntu/dapper/powerpc/nm-applet/0.5.1-0ubuntu19
https://launchpad.net/distros/ubuntu/dapper/i386/nm-applet/0.5.1-0ubuntu19

if you get a message about "The NetworkManager applet could not find some required resources. It cannot continue." then run
gtk-update-icon-cache -f /usr/share/icons/hicolor/
(see Bug #37128 )
(i had to run it with sudo)

[Andrew Jorgensen (ajorg)]

The bug as stated still remains but it appears that network-manager is working again. Did someone modify it so that it falls back to controlling the interface itself if it knows that wpa-supplicant can't handle it?

[Reinhard Tartler (siretart)]

In what cases does network-manager work again for you?
according to https://launchpad.net/distros/ubuntu/dapper/+source/network-manager/+changelog
network-manager does no longer use wpasupplicant for unencrypted networks. wpasupplicant had a bug which prevent WEP to be used with the wext driver backend, which has been fixed by the last upload

[Matt Bretl (mpbretl)]

I just tried the latest network-manager (0.6.2-0ubuntu3), but still can't connect using 64-bit WEP. 0.5.1-19 works like a charm.

[Reinhard Tartler (siretart)]

what version of wpa_supplicant?

[Matt Bretl (mpbretl)]

wpasupplicant-0.4.8-3ubuntu1 (the latest AFAIK)

[Scott James Remnant (Canonical) (canonical-scott)]

Sounds like a clear wpasupplicant problem!

[Reinhard Tartler (siretart)]

No, it is a rt2500 driver problem. It doesn't want to be used with wpasupplicant at all, because it seems to bring in an own supplicant in kernel-space:
https://wiki.ubuntu.com/WifiDocs/RalinkRT2500?action=show&redirect=Rt2500WirelessCardsHowTo

We have several options from here:
1.) Fix network-manager to use the rt2500 supplicant
2.) fix rt2500 to implement WE19 fully so wpasupplicant can be used with 'wext' driver backend.
3.) implement support for private rt2500 ioctls in both rt2500 and wpasupplicant

Option 3 is very likely to be rejected by wpasupplicant upstream, and I assume by rt2500 upstream as well, we shouldn't go that way.

I don't know how much work option 1 would be, and I consider Option 2 as the only feasible long term option.

[Reinhard Tartler (siretart)]

Reassigning back to linux-source-2.6.15. In order for rt2500 to work with wpasupplicant, it needs to implement WE19. Currently, it seems to implement its own supplicant in kernel space: see https://wiki.ubuntu.com/Rt2500WirelessCardsHowTo/

[Andrew Jorgensen (ajorg)]

> what version of wpa_supplicant?

0.6.2-0ubuntu3, but unfortunately for me Scott just reverted the change that fixed it for me. 0.6.2-0ubuntu4 will not work.

I was testing it against an unencrypted network.

[Andrew Jorgensen (ajorg)]

> 2.) fix rt2500 to implement WE19 fully so wpasupplicant can be used with 'wext' driver backend.

This is sure to be the correct approach but you will get no help from upstream (though I imagine they'll accept the patches) because they are working on a complete rewrite of the driver (which looks to not be done for a good long time).

[seanh (seanh)]

In Dapper, I reverted to nm-applet 0.5.1 and network-manager 0.5.1 and after running 'sudo gtk-update-icon-cache -f /usr/share/icons/hicolor/' to get past the "could not find some required resources" error I still have the same issue - nm-applet can't see any networks/devices.

[Eric Zinn (mistasparkalo)]

Well, I don't know if this will complicate the issue at all, but I'm having the same problem with a card using the Ti ACX100 chipset 0_o. If I use NM version 0.5.1, then I have no issues and everything runs pretty smoothly, if I use version 0.6.1 or higher, it doesn't.

Running with the option --no-daemon yields a loop of wpasupplicant messages. Using version 0.6.1 or higher, I'm unable to connect to any network, not even unencrypted or WEP, it just hangs in this loop.

[Adam McMaster (adammc)]

I'm testing Feisty right now, and NM doesn't give the option to connect with WPA -- I suspect this is the same bug.

[Genizzz (gabor-pierpont-gmail)]

Problem Definition:
KNetworkmanager hangs on "Activation stage: Configuring device".
Finally it tells that it's disconnected.

Environment: Kubuntu feisty herd-4
Driver: Ralink RT2600
Encryption: WEP 128 bit

[sam tygier (samtygier)]

no improvement with feisty so adding linux source 2.6.20.

this will be more visible now that NM is default

[Cyclops (rms)]

fortunately network-manager can be removed, but it's sad to do so. After removing NM, though, I'm suffering from this other annoying bug: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/78037

[kbang (kristian-bang)]

I see a similar problem on Ubuntu 7.04, kernel 2.6.20-15-generic. The Asus 107g PCMCIA card is detected and is trying to connect but gets no connection. I have tried both no encryption, WEP 64bit encryption, WEP 128bit encryption and WPA-PSK encryption but with no luck. Also i noted that network-manager only showed WEP 64 and WEP 128 encryption and not WPA or no encryption even though the router was configured to no password or WPA-PSK.

Then I uninstalled network-manager and network-manager-gnome, and inserted the following to /etc/network/interfaces:

iface ra0 inet dhcp
        pre-up ifconfig ra0 up
        pre-up ifconfig ra0 down
        pre-up ifconfig ra0 up
        pre-up ifconfig ra0 down
        pre-up iwconfig ra0 essid "MyRouterName"
        pre-up iwconfig ra0 mode Managed
        pre-up iwpriv ra0 set AuthMode=WPAPSK
        pre-up iwpriv ra0 set EncrypType=TKIP
        pre-up iwpriv ra0 set WPAPSK="MySecretPassword
        pre-up ifconfig ra0 up
auto ra0

and rebooted. The network has worked with no problems for a couple of weeks now. The router is an Asus 500g deluxe and configured to use WPA-PSK.

I would think there is a defect in the network-manager application.

See https://help.ubuntu.com/community/WifiDocs/Driver/RalinkRT2500

[Reinhard Tartler (siretart)]

kbang <email address hidden> writes:
> I would think there is a defect in the network-manager application.

Please be assured that this is not the case here. the rt2500 driver does
simply not implement the interface (called wireless extensions in linux)
which network-manager expects and needs to work.

ifupdown (/etc/network/interfaces) just use plain the wireless-utils
tools, which only need a subset of the functionality network-manager needs

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

[wilderness wanderer (jdmfilter-spam)]

Thanks, kbang.

Your solution worked for me, modified slightly as I'm using WEP:

iface ra0 inet dhcp
        pre-up ifconfig ra0 up
        pre-up ifconfig ra0 down
        pre-up ifconfig ra0 up
        pre-up ifconfig ra0 down
        pre-up iwconfig ra0 essid "MyRouterName"
        pre-up iwconfig ra0 key "MyKeyInHex"
        pre-up iwconfig ra0 mode Managed
        pre-up ifconfig ra0 up
auto ra0

Now I have wireless connectivity which survives a reboot.

[Andrew Jorgensen (ajorg)]

If you're only using WEP you shouldn't need any of that. I use the following:

iface ra0 inet dhcp
wireless-essid ESSID
wireless-key s:ASCII-WEP-key

It works fine. This can be configured through network-admin just fine. It's really only WPA and network-manager that suffer.

[Zac Bowling (zac)]

this is similar to the rt73usb bug but slightly different

[sam tygier (samtygier)]

a simple work around

System -> Administration -> Networking

choose the rt2500 card
click properies.
disable roaming.
set your network name, and put in any WEP key you might need
for most network setups choose the DHCP configuration.

[eppy 1 (choppy121212)]

The only problem is that WEP can be cracked in literally two minutes.

[Richie Ward (richies)]

Where are we going to find a developer to fix this?

[Chris Wagner (chris-wagner)]

Does anyone here have any idea what resolving this entails? How much work is it? Is it something that a virgin kernel developer could learn to do (without spending years of learning kernel development skills or wireless hacking skills)? Or is it much too difficult for a newb?

[Reinhard Tartler (siretart)]

Contacting the developers at http://prism54.org might be a good start.

[Sam Morris (yrro)]

Try out the new rt2x00 module instead. This is the module that will eventually be merged into the Linux kernel.

[Gaute (lindkvis)]

"Try out the new rt2x00 module instead. This is the module that will eventually be merged into the Linux kernel."

Unfortunately, the rt2x00 module seems pretty much unmaintained and is not reported to support the Linux Wireless Extensions yet. I found some discussion about this back in July:
http://mail.gnome.org/archives/networkmanager-list/2006-July/msg00054.html

Sadly, nothing seems to have happened with it since.

If at least Network Manager worked with WEP and without any security that would at least be something.

[Chris Wagner (chris-wagner)]

On Thu, 2007-04-26 at 18:54 +0000, Gaute wrote:
> Unfortunately, the rt2x00 module seems pretty much unmaintained and is not
> reported to support the Linux Wireless Extensions yet. I found some
> discussion about this back in July:
> http://mail.gnome.org/archives/networkmanager-list/2006-July/msg00054.html

What a shame... Does anyone have any clue as to which of the two
drivers is in better shape? I.e., which would be a better bet to hack
on?

[Andrew Jorgensen (ajorg)]

Let me clarify:

rt2500 (note the 5) is the old driver which does not support the wireless extensions and which is included in Ubuntu. It is the driver in question here which is causing people grief. It is not being actively developed because all efforts are going into completing the new driver.

rt2x00 (note the x) is the new driver which is not yet completed and is largely unusable at the moment (YMMV). It is being very actively developed and will surely implement the wireless extensions correctly when it becomes stable. The developers are working closely with upstream (kernel) and you will see the driver show up in the main kernel when it is ready. There's a good chance you won't see it in Ubuntu for another year.

I have no knowledge as to how much work it would take to implement the extensions in the rt2500 (old) driver but I am reasonably sure that the patch will be gratefully accepted upstream if it is complete and of good quality.

My personal opinion is that it would be worth while for someone to implement the wireless extensions in the old driver. I'm biased though because I use several RT2500s and because I am pessimistic about the time it may take for the new driver to be completed. I could be wrong.

I recall a complaint on planet.gnome.org some time ago about another driver that was missing WEXT which was answered almost immediately by a hacker posting a patch for it. I'll bet if the SABDFL said that it should be done it would take one of his excellent kernel hackers less than a week to get it working.

[Chris Wagner (chris-wagner)]

Thanks for the detail Andrew.

Would you (or anyone else) happen to know what the ''interface'' used by the wireless command line tools is? I've been snooping around the kernel source, and it looks like the Wireless Extensions interface consists of a bunch of functions with names like ''driver_wx_get_attribute()'' and ''driver_wx_set_attribute()''. For example, the ipw2200 driver has a function name ''ipw_wx_get_essid()'' for retrieving a device's associated ESSID. I figure, there must be a standard set of functions used by the command line tools; it might be as simple as ''wrapping'' those up in some xxx_wx_set_xxx()/xxx_wx_get_xxx() functions (?).

[Darren Albers (dalbers)]

This same situation came up for the Madwifi drivers, here is the ticket with the patch. This might help someone get started.

http://madwifi.org/ticket/462

[Matevž Jekovec (matevz-jekovec)]

I'm opening a new bug 110590. This is a feature request for inclusion of rt2x00 driver into the main Ubuntu kernel instead of the legacy ones. IMO this feature should be implemented ASAP because the majority of non-integrated wireless cards are nowadays rt2x based. When done, this bug should be fixed.

[Launchpad Janitor (janitor)]

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.