Bug 451422

Summary: rt2500 card no longer connects at all
Product: [Fedora] Fedora Reporter: Paul Henshall <zen77630>
Component: kernelAssignee: John W. Linville <linville>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 9CC: al.an, azexptech, b1r63r, bhockney, dennis.bruno, eric.tanguy, ivdoorn, ivnmad, jbuck, jmpif, kernel-maint, kmcmartin, louizatakk, m.afgani, marynya, misek, rafapp, tsimi, vic
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-09-29 18:12:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 442790    
Attachments:
Description Flags
Short ping illustrating periodic interference none

Description Paul Henshall 2008-06-14 11:13:19 UTC
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.

Comment 1 Paul Henshall 2008-06-14 11:13:19 UTC
Created attachment 309354 [details]
Short ping illustrating periodic interference

Comment 2 Ivan Virgili 2008-06-17 21:00:13 UTC
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.

Comment 3 Ra P. 2008-06-22 13:42:09 UTC
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



Comment 4 Ivan Virgili 2008-06-26 18:25:19 UTC
I have just tested kernel kernel-2.6.25.9-74.fc9.i686, no luck.

Comment 5 Paul Henshall 2008-06-26 23:19:37 UTC
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.

Comment 6 Vic Ricker 2008-07-04 00:29:54 UTC
It still doesn't work at all under 2.6.25.9-76.fc9.i686.


Comment 7 Ivan Virgili 2008-07-05 07:44:23 UTC
It still doesn't work under 2.6.25.10-85.fc9 either.

Comment 8 Vaclav "sHINOBI" Misek 2008-07-13 15:38:45 UTC
Is this bug the same as #452647?

Comment 9 Ivo van Doorn 2008-08-02 10:38:15 UTC
John, this issue should be fixed by wireless-testing commit:
    3da0ce9de317f8d685389ee80b6a8c3039d96055
    rt2500pci: restoring missing line

Comment 10 Florent Le Coz 2008-08-08 17:10:36 UTC
>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...

Comment 11 Todd Simi 2008-08-12 02:45:51 UTC
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

Comment 12 birger 2008-08-19 08:42:27 UTC
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.

Comment 13 John W. Linville 2008-08-20 13:22:41 UTC
*** Bug 459573 has been marked as a duplicate of this bug. ***

Comment 14 Mike 2008-08-20 19:15:21 UTC
It is working for me in this kernel only.

2.6.25-14.fc9.i686

Comment 15 John W. Linville 2008-08-26 15:37:38 UTC
*** Bug 450401 has been marked as a duplicate of this bug. ***

Comment 16 Paul Henshall 2008-09-12 22:15:40 UTC
Still fails in kernel-2.6.26.3-29.fc9.i686

Comment 17 Eric Tanguy 2008-09-13 08:50:20 UTC
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!

Comment 18 Paul Henshall 2008-09-15 13:21:50 UTC
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.

Comment 19 Paul Henshall 2008-09-15 23:04:37 UTC
(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.

Comment 20 Paul Henshall 2008-09-17 18:52:28 UTC
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.

Comment 21 Chuck Ebbert 2008-09-21 18:06:04 UTC
The one-line fix is in 2.6.26.5-45

Comment 22 Tonino 2008-09-28 12:16:01 UTC
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

Comment 23 John W. Linville 2008-09-29 18:12:22 UTC
Closing on the basis of comment 22...

Comment 24 John W. Linville 2008-09-29 18:15:18 UTC
*** Bug 452647 has been marked as a duplicate of this bug. ***

Comment 25 Joe Buck 2008-10-03 03:35:29 UTC
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.

Comment 26 John W. Linville 2008-10-03 13:44:17 UTC
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.

Comment 27 Jorge A. Montes Perez 2008-10-03 16:28:27 UTC
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.

Comment 28 Mostafa Afgani 2008-10-05 19:08:37 UTC
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.

Comment 29 Mike Hughes 2008-11-14 18:51:19 UTC
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