Description of problem: The rt2500pci driver has been having issues for a while, with maximum throughput of around 20k per second. Now it seems to have stopped being able to connect entirely. Version-Release number of selected component (if applicable): kernel-2.6.25.6-55.fc9.i686 How reproducible: Steps to Reproduce: 1. Try to connect using NetworkManager Actual results: Failure to connect. Expected results: Successful connection. Additional info: I think the last time this driver worked was around the and of the 2.6.23 drivers to Fedora 8. Might be worth noting that my wireless network does suffer from interference, generally showing up as increased ping times every few seconds. I am currently using ndiswrapper as a stop-gap, but will retest periodically.
Created attachment 309354 [details] Short ping illustrating periodic interference
I can confirm I am having the same problem. The only kernel on F9 that seems to work is 2.6.25.3-18.fc9 (with the speed limitation mentioned in bug report 442790). If I use any other kernel the card fails to connect. I have just tested kernel 2.6.25.7-64.fc9, but I had no luck.
I failed to make rt2500 wi-fi adapter connect to any network with kernel-2.6.25.6-55 as well. It sees networks with /sbin/iwlist but do not connect after call to /sbin/ifup wlan0 I got following message in /var/log/messages kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
I have just tested kernel kernel-2.6.25.9-74.fc9.i686, no luck.
Tested the latest kernel from rawhide and this problem persists. Also with that kernel the driver generates what I think is a lock-dep warning on reboot.
It still doesn't work at all under 2.6.25.9-76.fc9.i686.
It still doesn't work under 2.6.25.10-85.fc9 either.
Is this bug the same as #452647?
John, this issue should be fixed by wireless-testing commit: 3da0ce9de317f8d685389ee80b6a8c3039d96055 rt2500pci: restoring missing line
>John, this issue should be fixed by wireless-testing commit: > 3da0ce9de317f8d685389ee80b6a8c3039d96055 > rt2500pci: restoring missing line Should this be fixed by the kernel 2.6.25.14-108 ? Because it's not...
Hi, Same problem. I can iwlist scan the rt2500 and see my router/access point but cannot connect. I can iwconfig the rt2500 and see it's getting some settings, i.e. it found the correct ssid. I can connect with a different wireless card, but that's for a different machine. Network Manager sees the card and will try to connect with no luck. Thanks Todd Fedora 9 Linux localhost.localdomain 2.6.25.11-97.fc9.i686 #1 SMP
Me too! I have a PCMCIA card that works with the rt2x00 driver in the original Fedora 9 kernel (2.6.25-14 if I remember correctly). It does not work with any other kernel I have tried so far, including 2.6.25.14-108. For anyone needing a working card, try 2.6.25-14 and see if it works for you as well. I am running that kernel on my otherwise fully updated laptop with only the expected problems (mostly that suspend/resume doesn't work at all). It seems like wlan throughput is very low, though.
*** Bug 459573 has been marked as a duplicate of this bug. ***
It is working for me in this kernel only. 2.6.25-14.fc9.i686
*** Bug 450401 has been marked as a duplicate of this bug. ***
Still fails in kernel-2.6.26.3-29.fc9.i686
I have the same problem in fedora 8 since kernel-2.6.24.7-92.fc8 which the last one with correct association. Today i tried kernel-2.6.26.5-19.fc8 and the problem is still here. Why this bug take so long to be solved ? It's very annoying!
Looking at the source package, and assuming that this is actually fixed by the patch r2500pci: restoring missing line, then the mainline code is actually correct, but it is repeatedly being broken in Fedora by the linux-2.6-wireless-pending.patch. All that would be required, I believe, would be to change this part of the patch: - !!(control->flags & - IEEE80211_TXCTL_LONG_RETRY_LIMIT)); - rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skbdesc->data_len); + test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags)); to - !!(control->flags & - IEEE80211_TXCTL_LONG_RETRY_LIMIT)); + test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags)); Thus leaving the line rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skbdesc->data_len); intact. I will try to verify this.
(In reply to comment #18) > Looking at the source package, and assuming that this is actually fixed by the > patch r2500pci: restoring missing line, then the mainline code is actually > correct, but it is repeatedly being broken in Fedora by the > linux-2.6-wireless-pending.patch. > > All that would be required, I believe, would be to change this part of the > patch: > - !!(control->flags & > - IEEE80211_TXCTL_LONG_RETRY_LIMIT)); > - rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skbdesc->data_len); > + test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags)); > > to > > - !!(control->flags & > - IEEE80211_TXCTL_LONG_RETRY_LIMIT)); > + test_bit(ENTRY_TXD_RETRY_MODE, &txdesc->flags)); > > Thus leaving the line > rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skbdesc->data_len); > intact. > > I will try to verify this. Hmmm... it seems that skbdesc no longer has a member named data_len. Looking at it this line should now either be: rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skb->len); or rt2x00_set_field32(&word, TXD_W0_DATABYTE_COUNT, skb->len - skddesc->desc_len); The various other files seem to be split more or less 50/50 on which one it should be. [PATCH] rt2x00: skb->data pointer should not include TX descriptor from Mattias Nissler on 29th August seems to imply the former. This is currently building, so we shall see.
That change at least enables the driver to authenticate, rather than timing out when authenticating. Unfortunately the driver seems to be completely broken in other ways that stop it actually communicating at all.
The one-line fix is in 2.6.26.5-45
Fantastic! It works! even I still have to keep this line in my rc.local: /sbin/iwconfig wlan0 rate 54M fixed or my throughput will be 1M not more
Closing on the basis of comment 22...
*** Bug 452647 has been marked as a duplicate of this bug. ***
Unforutnately, my card is still broken with kernel 2.6.26.5-45. I have an ASUS WL-107g (rt2500 based), and I've seen the same problems others have reported here. The card successfully detects the ESSID of an unencrypted network, but cannot connect. Like Tonino, I'm seeing the speed set to 1M, but this doesn't change if I use the iwconfig command. dmesg shows Registered led device: rt2500pci-phy1:radio ADDRCONF(NETDEV_UP): wlan0: link is not ready wlan0: authenticate with AP 02:1b:11:e2:9a:85 wlan0: authenticated wlan0: associate with AP 02:1b:11:e2:9a:85 wlan0: RX AssocResp from 02:1b:11:e2:9a:85 (capab=0x401 status=0 aid=1) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: disassociating by local choice (reason=3) wlan0: no IPv6 routers present wlan0: authenticate with AP 02:1b:11:e2:9a:85 wlan0: authenticated wlan0: associate with AP 02:1b:11:e2:9a:85 wlan0: RX ReassocResp from 02:1b:11:e2:9a:85 (capab=0x401 status=0 aid=1) wlan0: associated wlan0: disassociating by local choice (reason=3) wlan0: authenticate with AP 02:1b:11:e2:9a:85 wlan0: authenticated wlan0: associate with AP 02:1b:11:e2:9a:85 wlan0: RX AssocResp from 02:1b:11:e2:9a:85 (capab=0x401 status=0 aid=1) wlan0: associated wlan0: disassociating by local choice (reason=3) ------------------------------ /var/log/messages says: DHCP transition took too long (>45s), stopping it. I verified that my old 802.11b card can connect to this same network.
Joe, AFAICT you are associating successfully. The "disassociating by local choice" indicates that some userland application (probably wpa_supplicant) has requested a disassociation. I think it would be best if you were to open a new bug, probably against wpa_supplicant or NetworkManager -- if this is a driver problem, I'll need some indication from the userland guys as to what the driver or mac80211 might be doing that causes them to request the disassociation.
I get 'wlan0: disassociating by local choice (reason=3)' too. But if I set static address instead of DHCP, it works very well. I have to run /sbin/iwconfig wlan0 rate 54M fixed because the card always starts with 1M.
My ASUS WL-130g: 05:00.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01) Subsystem: ASUSTeK Computer Inc. WL-130g Flags: bus master, slow devsel, latency 32, IRQ 20 Memory at ea104000 (32-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 Kernel driver in use: rt2500pci Kernel modules: rt2500pci works again with 2.6.26.5-45.fc9.x86_64. It associates successfully using WPA2 and obtains the address automatically using DHCP. The automatically selected rate, however, is 1M as observed in the posts above. Other component versions: dhclient-4.0.0-18.fc9.x86_64 NetworkManager-0.7.0-0.11.svn4022.4.fc9.x86_64 wpa_supplicant-0.6.3-6.fc9.x86_64 wireless-tools-29-2.fc9.x86_64 Hope this information helps someone.
Kernel: 2.6.26.6-79.fc9.i686 Device: Foxcomm WLL-3350 PCI card lspci: 01:06.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01) lsmod: rt2500pci 18048 0 rt2x00pci 9728 1 rt2500pci rt2x00lib 32768 2 rt2500pci,rt2x00pci dmesg: wlan0: deauthenticated wlan0: authenticate with AP 00:21:91:09:32:d7 wlan0: authenticated wlan0: associate with AP 00:21:91:09:32:d7 wlan0: RX AssocResp from 00:21:91:09:32:d7 (capab=0x431 status=0 aid=1) wlan0: associated wlan0 (WE) : Wireless Event too big (268) wlan0: disassociating by local choice (reason=3) Anyone know what "(WE) : Wireless Event too big (268)" means? thanks, Mike