Bug 469120 - [rt2500pci] [rtl8187] cannot establish connection
[rt2500pci] [rtl8187] cannot establish connection
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 472183 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-29 20:56 EDT by Gian Paolo Mureddu
Modified: 2010-10-06 08:28 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-01 13:25:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages featuring NetworkManager and DHCP error messages with RT2500 failure to connect (33.71 KB, application/octet-stream)
2009-06-09 15:41 EDT, David W. Legg
no flags Details

  None (edit)
Description Gian Paolo Mureddu 2008-10-29 20:56:59 EDT
Description of problem:
When connecting to a security enabled network (WEP/WPA), the computer cannot stablish a connection using the right key and security protocol.

Version-Release number of selected component (if applicable):
NetworkManager-0.7.0-0.11.svn4229.fc10.x86_64
wpa_supplicant-0.6.4-2.fc10.x86_64
kernel-2.6.27.4-58.fc10.x86_64


How reproducible:
Always, since last update.

Steps to Reproduce:
1. Try to establish a connection to a network with security enabled.
2. Enter the key according to the security protocol.
  
Actual results:
Connection fails

Expected results:
Establish a connection.

Additional info:
NetworkManager does not seem to store the right key or protocol in the connections when editing the stored connection settings. When attempting to connect dmesg shows this:

[dmesg]
wlan0: authenticate with AP 00:40:10:10:00:03
wlan0: authenticate with AP 00:40:10:10:00:03
wlan0: authenticated
wlan0: associate with AP 00:40:10:10:00:03
wlan0: RX AssocResp from 00:40:10:10:00:03 (capab=0x411 status=0 aid=1)
wlan0: associated
wlan0: disassociating by local choice (reason=3)
[/dmesg]

When negotiating, I can see both dots green, then the prmpt again.

Hardware: Realtek 8187B
Comment 1 Mark Locascio 2008-11-01 12:25:51 EDT
I have a similar problem, only I can't connect to an unencrypted network.

The last two kernels I've gotten from updates have been unable to connect to the wireless network (2.6.27.4-58.fc10.i686 and 2.6.27.3-44.fc10.i686). The last one that worked was 2.6.27-0.352.rc7.git1.fc10.i686, which I am running now with no other network-related problems.

Other packages:
NetworkManager-0.7.0-0.11.svn4229.fc10.i386
wpa_supplicant-0.6.4-2.fc10.i386

This machine uses an old Microsoft MN-520 wireless card which has worked flawlessly on various linux distributions (including the last several Fedora releases) for the last 4 years. It has an Orinoco chipset.

The end of my dmesg output:
eth2: no IPv6 routers present
fuse init (API version 7.9)
wifi0: CMD=0x0121 => res=0x7f, resp0=0x0004
wifi0: hfa384x_set_rid: CMDCODE_ACCESS_WRITE failed (res=127, rid=fc48, len=2)
wifi0: LinkStatus=2 (Disconnected)
wifi0: LinkStatus: BSSID=44:44:44:44:44:44
wifi0: LinkStatus=2 (Disconnected)
wifi0: LinkStatus: BSSID=44:44:44:44:44:44
eth2: Preferred AP (SIOCSIWAP) is used only in Managed mode when host_roaming is enabled
wifi0: LinkStatus=1 (Connected)
wifi0: LinkStatus: BSSID=00:50:f2:72:bb:ba
wifi0: LinkStatus=2 (Disconnected)
wifi0: LinkStatus: BSSID=00:50:f2:72:bb:ba
wifi0: LinkStatus=1 (Connected)
wifi0: LinkStatus: BSSID=00:50:f2:72:bb:ba

ifup output:
# ifup wifi0
Error for wireless request "Set Mode" (8B06) :
    SET failed on device eth2 ; Operation not supported.

Determining IP information for eth2...Nothing to flush.

Then it just hangs there until I hit ctrl-C, after which dmesg says

wifi0: LinkStatus: BSSID=00:50:f2:72:bb:ba
wifi0: LinkStatus=2 (Disconnected)
wifi0: LinkStatus: BSSID=44:44:44:44:44:44
wifi0: LinkStatus=2 (Disconnected)
wifi0: LinkStatus: BSSID=44:44:44:44:44:44
wifi0: LinkStatus=1 (Connected)
wifi0: LinkStatus: BSSID=00:50:f2:72:bb:ba
wifi0: invalid skb->cb magic (0x00000168, expected 0xf08a36a2)
wifi0: invalid skb->cb magic (0x00000168, expected 0xf08a36a2)
wifi0: invalid skb->cb magic (0x00000168, expected 0xf08a36a2)
wifi0: invalid skb->cb magic (0x00000168, expected 0xf08a36a2)
Comment 2 Gian Paolo Mureddu 2008-11-02 00:09:32 EDT
I should have mentioned that I don't seem to be able to connect to unencrypted networks either. Just tried today at a local hotspot and while getting very good signal readings in Fedora Rawhide (and confirmed later in Vista), I couldn't connect to the network. Unencrypted network connection negotiation takes longer than protected networks, and both take a LONG time (1+ minute negotiation) before stating that the connection couldn't be stablished, or prompting for the Network passphrase/security token.
Comment 3 Mark Locascio 2008-11-02 11:19:13 EST
For what it's worth, I tried compiling and installing the vanilla 2.6.27.4 kernel, and the problem occurred with that as well.
Comment 4 Anne 2008-11-17 10:45:43 EST
More info, after many tests:

F10-Snapshot 3 installed on an Acer Aspire One - kernel 2.6.27.3-34rc1 - wireless worked, but there was no wired connection.  At the next boot the wired connection worked, but wireless was lost, and has not worked since.

Typical event - First it offers me the chance to connect to hidden networks.  I give it the ESSID, set it to WPA and give it the passphrase.  It whirs for a while, then a 
dialogue box opens asking me to give a WEP key.  There is no option to set the WPA key this time.

Kernels tested since that date:
2.6.27.4-79
2.6.27.5-94
2.6.27.5-100
2.6.27.5-109 -  all i686

/etc/sysconfig/networking/devices/ifcfg-wlan0 says
# Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter

On several occasions NetworkManager has reported a successful link, but at 0%.  Further investigation shows that it is to a different subnet.  At no time has any 
other network been listed by NetworkManager, and the nearest other wifi network does not use the IP range mentioned.  Also, it reports that it is connected to my ESSID.

'service network status' gives

Configured devices:
l0 eth0 wlan0
Currently active devices:
lo eth1 wmaster0 wlan0

lsmod | grep ath gives
ath5k		 17164	0
mac80211	112520	1	ath5k
cfg80211	 23816	2	ath5k,mac80211

nm-tool                                                                            

NetworkManager Tool

State: connected

- Device: eth1 
----------------------------------------------------------------
  Type:              Wired                                                     
  Driver:            r8169                                                     
  State:             connected                                                 
  Default:           yes                                                       
  HW Address:        00:1E:68:BD:EF:73                                         

  Capabilities:
    Supported:       yes
    Carrier Detect:  yes
    Speed:           100 Mb/s

  Wired Settings

  IPv4 Settings:
    Address:         192.168.0.92
    Prefix:          24 (255.255.255.0)
    Gateway:         192.168.0.1       

    DNS:             192.168.0.1


- Device: wlan0 
----------------------------------------------------------------
  Type:              802.11 WiFi                                                
  Driver:            ath5k_pci                                                  
  State:             disconnected                                               
  Default:           no                                                         
  HW Address:        00:22:33:44:55:66     #obscured                                     

  Capabilities:
    Supported:       yes

  Wireless Settings
    WEP Encryption:  yes
    WPA Encryption:  yes
    WPA2 Encryption: yes

  Wireless Access Points
---
 iwlist scanning
lo        Interface doesn't support scanning.

wmaster0  Interface doesn't support scanning.

wlan0     No scan results

eth1      Interface doesn't support scanning.

pan0      Interface doesn't support scanning.

---
ifconfig wlan0

wlan0     Link encap:Ethernet  HWaddr 
00:22:33:44:55:66
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 
frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 
carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
---
iwconfig wlan0
wlan0     IEEE 802.11bg  ESSID:""
          Mode:Managed  Frequency:2.412 GHz  Access 
Point: Not-Associated
          Tx-Power=27 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 
B
          Encryption key:off
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid 
frag:0
          Tx excessive retries:0  Invalid misc:0   Missed 
beacon:0
---

On one of those 'bogus connections' - 
Running iwconfig wlan0 again I now get

wlan0     IEEE 802.11bg  ESSID:"myESSID"
          Mode:Ad-Hoc  Frequency:2.412 GHz  Cell: 
36:8F:3A:45:3F:BC
          Tx-Power=27 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 
B
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid 
frag:0
          Tx excessive retries:0  Invalid misc:0   Missed 
beacon:0
---
Running the connection again, changing the ad-hoc to Infrastructure (the only other option, Managed being absent) the connection was lost and could no longer be found.
---
The best I ever achieved was

wlan0     IEEE 802.11bg  ESSID:"myESSID"
          Mode:Managed  Frequency:2.412 GHz  Access 
Point: Not-Associated
          Tx-Power=27 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 
B
          Encryption key:off
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid 
frag:0
          Tx excessive retries:0  Invalid misc:0   Missed 
beacon:0

It has been suggested that this may be a kernel bug affecting the ath5k driver.
Comment 5 Bug Zapper 2008-11-25 23:28:38 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Gian Paolo Mureddu 2008-11-26 02:15:37 EST
I'm going to try to fresh-install F10 rather than "upgrade from rawhide to release" on this laptop and see what happens, if I have the same issue, I'll report back.
Comment 7 Mark Locascio 2008-11-27 12:47:16 EST
Just installed the F10 release from the live CD. On the first boot, with kernel 2.6.27.5-117.fc10.i686, I can connect to the wireless network. It appears to be fixed. I'm going to reboot a couple times and if everything still works I'll run the updates and see if it's still ok.
Comment 8 David W. Legg 2008-11-27 15:17:27 EST
I think this one ought to be "high" severity because some systems are completely unable to connect to networks.
Comment 9 David W. Legg 2008-11-28 11:54:27 EST
I have a fully-updated F10 as of right now, and these are the wireless problems that I am seeing (some of them must relate to this bug report):

1. The network-device-control gui will not let me save my settings for a wlan0 device (rt2500 PCMCIA card).

2. knetwork-manager and the gnome network manager can see my wireless network, but fails to get DHCP to allocate it an IP address; it times-out.

Both 1 and 2 above occur whether I have WEP on or off on my Netgear router.

So, I think there are several bugs with connecting to wireless networks.

The title of this bug ought to be changed from 'Rawhide' to 'latest F10' or similar.

Hope that helps :)
Comment 10 Gian Paolo Mureddu 2008-11-28 17:26:23 EST
Indeed, installed F10 on the laptop I'm seeing this problem occur, and it has happened just like with Rawhide. Updates applied and still getting the same behavior. Tried some LiveCD images from other distributions with similar versions of components and there does not seem to be a problem with NM or WPASupplicant or DHCP there, only F10 shows these problems (thus far). Is there a way to help troubleshoot this? I realize that simply stating "cannot connect" is not as helpful as what messages are being printed to dmesg or the like, so what would you recommend doing to try and locate the origin of these problems?
Comment 11 Anne 2008-11-29 05:25:56 EST
F10 on Acer Aspire One - temporarily turned NM of and configured with s-c-n.  The result is the same.  Possibly helpful notes:

boot message
ADDRCONF(NETDEV_UP):wlan0: link is not ready

ifup wlan0
Determining IP information for wlan0...Nothing to flush.
failed

This seems to imply that NM is not the problem, but either the ath5k driver or wpa_supplicant?
Comment 12 Gian Paolo Mureddu 2008-11-29 18:08:43 EST
I would think that rather than drivers or NM as such, the problem seems to be either or both, WPA supplicant and the 802.11 kernel stack. I just tried the latest stable LiveCD image of another popular distro, with virtually equal software versions as F10, and there I experienced the problem as well, with all and the very same dmesg messages, which is to say the least, odd, and points towards either or a relation between the drivers, kernel 802.11 stack, WPA_Supplicant and Network Manager, since there seems to be a connection going on, but then *dropped* due to "local choice" (for whatever that may mean), "wlan0: disassociating by local choice (reason=3)", I would think that the problem lies within WPA_Supplicant rather than the other components, but then again, I'm not sure how to properly debug this.

PS: Summary changed from Rawhide to F10 to reflect the current state of affairs.
Comment 13 Gian Paolo Mureddu 2008-12-02 11:29:28 EST
As I said before, I tried to build from source the latest WPA Supplicant code under Linux, but have failed miserably (I'm told Makefile is missing a config file, but I can see no configure script anywhere, does it make use of Auto Tools at all?). Keeping this in mind I have tried a couple more LiveCD images of other distributions (some based on Fedora 10 even) and with all of them with recent versions of kernel (for the drivers), NM and WPA supplicant, I get the very same behavior. Now what I don't fully understand is why does this happen with only a seemingly limited array of WLAN chipsets/cards?

What about trying to detrmine which adapters DO exhibit the problem and try to address those?

In my case I'm using a Realtek 8187B (USB) internal WLAN adapter.
Comment 14 David W. Legg 2008-12-12 12:18:07 EST
Just tried my RT2500 card with the latest F10 updates, latest kernel etc, and get this, but no connection:

Dec 12 17:11:23 stail00422 NetworkManager: <info>  Found new 802.11 WiFi device'wlan0'.
Dec 12 17:11:23 stail00422 NetworkManager: <info>  (wlan0): exported as /org/freedesktop/Hal/devices/net_00_0f_ea_e0_b6_16_0
Dec 12 17:11:27 stail00422 NetworkManager: <info>  (wlan0): device state change: 1 -> 2
Dec 12 17:11:27 stail00422 NetworkManager: <info>  (wlan0): bringing up device.
Dec 12 17:11:27 stail00422 kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Dec 12 17:11:27 stail00422 NetworkManager: <info>  (wlan0): preparing device.
Dec 12 17:11:27 stail00422 NetworkManager: <info>  (wlan0): deactivating device(reason: 2).
Dec 12 17:11:27 stail00422 NetworkManager: <info>  (wlan0): device state change: 2 -> 3
Dec 12 17:11:27 stail00422 NetworkManager: <info>  (wlan0): supplicant interface state:  starting -> ready
Dec 12 17:12:06 stail00422 NetworkManager: <WARN>  wait_for_connection_expired(): Connection (2) /org/freedesktop/NetworkManagerSettings/Connection/0 failed toactivate (timeout): (0) Connection was not provided by any settings service
Dec 12 17:12:21 stail00422 NetworkManager: <info>  (wlan0): device state change: 3 -> 2
Dec 12 17:12:21 stail00422 NetworkManager: <info>  (wlan0): deactivating device(reason: 0).
Dec 12 17:12:21 stail00422 NetworkManager: <info>  (wlan0): taking down device.

BTW: I'm getting this on a Pentium 3, so the platform should be changed from x86_64 to 'All' probably.
Comment 15 Anne 2009-01-23 12:41:57 EST
At some point early this month and up to yesterday, I was able to connect after giving a gnome-keyring-password.  However, connections were dropped randomly, and again NM could not re-connect.  I was told to install gnome-keyring-pam for better handling of the password.  After that I could not get a connection at all.

Finally, I installed knetworkmanager and removed NetworkManager-gnome.  I now hav a connection every time.

I think this brings the problem fairly and squarely to NM, as 
WPA is being handled correctly by knetworkmanager.
Comment 16 Anne 2009-01-23 14:32:14 EST
Excerpt from log during time when gnome-keyring-pam was installed, and prior to changing to knetworkmanager:

    kdm: :0: PAM adding faulty module: /lib/security/pam_gnome_keyring.so: 1 
Time(s)
    kdm: :0: PAM unable to dlopen(/lib/security/pam_gnome_keyring.so): 
/lib/security/pam_gnome_keyring.so: cannot open shared object file: No such 
file or directory: 1 Time(s)
    kdm: :0: gnome-keyring-daemon: couldn't lookup keyring component setting: 
Failed to contact configuration server; some possible causes are that you need 
to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a 
system crash. See http://www.gnome.org/projects/gconf/ for information. 
(Details -  1: Not running within active session)gnome-keyring-daemon: 
couldn't lookup ssh component setting: Failed to contact configuration server; 
some possible causes are that you need to enable TCP/IP networking for ORBit, 
or you have stale NFS locks due to a system crash. See 
http://www.gnome.org/projects/gconf/ for information. (Details -  1: Not 
running within active session)gnome-keyring-daemon: couldn't lookup pkcs11 
component setting: Failed to contact configuration server; some possible 
causes are that you need to enable TCP/IP networking for ORBit, or you have 
stale NFS locks due to a system crash. See 
http://www.gnome.org/projects/gconf/ for information. (Details
  -  1: Not running within active session): 5 Time(s)
Comment 17 Dan Williams 2009-02-14 07:42:04 EST
Are people still having problems with rtl8187 and latest kernel updates?  The issue with establishing connections is highly driver dependent.

Next, what type of connections are having the problem; all, or just WEP, or just WPA, etc?

Gian: if WEP, what type of WEP key is it (ASCII, Hex, or Passphrase), and how long is it?
Comment 18 Brent R Brian 2009-02-14 12:30:17 EST
bug 457441 is tracking rt2500 problems for those of you interested
Comment 19 Gian Paolo Mureddu 2009-02-15 00:50:15 EST
(In reply to comment #17)
> Are people still having problems with rtl8187 and latest kernel updates?  The
> issue with establishing connections is highly driver dependent.
> 
> Next, what type of connections are having the problem; all, or just WEP, or
> just WPA, etc?
> 
> Gian: if WEP, what type of WEP key is it (ASCII, Hex, or Passphrase), and how
> long is it?

Well, this issue doesn't seem to be driver-dependent, but rather Network Manger is messing up for some reason. I can establish the connection once I "hack" the correct key into the keyring... What I have seen that happens (with any new network that I register) is the following:

1.- When trying to establish the connection with Netowrk Manager, after introducing the key (WPA/WEP, any kind [hex, ascii, etc) the first attempt fails.

2.- When the prompt pops back up, and I select "show key", the key that NM presents is completely different from the one I actually entered (especially true for WEP-HEX).

3.- I have to resort to use either Seahorse or gnome-keyring-manager to actually change the key in the keyring to the correct value. Once done this, I can perfectly connect through NM to the new network.

I have seen this happening with either RealTek or RaLink hardware. I do not know if other chipsets have similar issues, or if this might be a problem of Network Manager + hardware type.
Comment 20 Brent R Brian 2009-02-15 08:08:45 EST
I have also seen the corrupted HEX KEY when "show key" is clicked using rt2500pci
Comment 21 Dan Williams 2009-02-15 09:33:48 EST
(In reply to comment #19)
> (In reply to comment #17)
> > Are people still having problems with rtl8187 and latest kernel updates?  The
> > issue with establishing connections is highly driver dependent.
> > 
> > Next, what type of connections are having the problem; all, or just WEP, or
> > just WPA, etc?
> > 
> > Gian: if WEP, what type of WEP key is it (ASCII, Hex, or Passphrase), and how
> > long is it?
> 
> Well, this issue doesn't seem to be driver-dependent, but rather Network Manger
> is messing up for some reason. I can establish the connection once I "hack" the
> correct key into the keyring... What I have seen that happens (with any new
> network that I register) is the following:
> 
> 1.- When trying to establish the connection with Netowrk Manager, after
> introducing the key (WPA/WEP, any kind [hex, ascii, etc) the first attempt
> fails.
> 
> 2.- When the prompt pops back up, and I select "show key", the key that NM
> presents is completely different from the one I actually entered (especially
> true for WEP-HEX).

That's some good info.  How many characters is your key?  It's definitely a WEP Hex key, not a 5 or 13 character WEP ASCII key, and not a 8 - 64 character WEP passphrase?
Comment 22 Brent R Brian 2009-02-15 11:05:56 EST
WEP HEX 

0x00112233445566778899AABBCC

13 hex digits
Comment 23 Dan Williams 2009-02-17 11:47:29 EST
Are you entering the key with or without the leading "0x"?  The 0x is not required (on any modern OS, Apple stopped using that a while ago even) and it shouldn't be needed when entering the password into NM.

If you enter the 0x, then it's 28 characters, and it's then a WEP passphrase, which is totally different.

WEP sucks.  As you can tell.  Let me know if not using the "0x" works for you.
Comment 24 Gian Paolo Mureddu 2009-02-17 12:28:57 EST
Indeed, WEP utterly sucks, but sadly is the only type of wireless security supported by many ISP-provided WiFi routers (at least down here in Mexico is pretty much the defacto standard, and 64-bit keys to top it all). Pretty much since NM was made standard in Fedora, and even before that (FC6 era, I believe) when you had to separately install it and enable it as a service, only a couple releases actually required that you used the 0x prefix for entering HEX keys. At any rate, I'll do a series of tests to change the key from WEP to WPA2 in my router (which is one of the few that actually does support that security scheme) and see what happens. Will report back any success or failure later today.
Comment 25 Dan Williams 2009-02-17 14:00:44 EST
Early release may have required the 0x prefix (which Apple used to use up until OS X 10.3 as well), but NM hasn't used the 0x prefix at least since 0.5 back in 2004/2005.  Please let me know how the testing goes.  Thanks!
Comment 26 Brent R Brian 2009-02-17 19:11:01 EST
No, the key is just hex, no 0x in front ... just trying to make it more "clear" ... that backfired nicely.  I will try to be more confusing in the future.

:>
Comment 27 Dainius 'GreatEmerald' 2009-05-10 08:19:33 EDT
I have the same problem on vanilla FC10. NetworkManager-gnome doesn't dynamically acquire IP addresses from the router via DHCP, and the connection only works if I set a static IP. But then I get speeds only up to 20KB/s (pretty much the same as bug #451422 ). The network keys (I use WPA) are changed (as mentioned in this report before). The real key is made of 8 letters, but they are changed to a hash of some sort that has 64 symbols. Using seahorse makes no difference, as when changed, the NetworkManager asks me about the key again, and changes it to the hash again. But seeing that I can still use the Internet (with a static IP and 20 KB/s), maybe that's intended?
I've also tried switching to KNetworkManager (actually, now both Gnome and K managers are installed, and they work as one :) ), and it's the same.

Finally I've attempted to make the connection manageable by the system-config-network instead of NetworkManager, but it seems it doesn't support WPA keys at all. Then I tried WPA Supplicant, but it needs DHCPD, and initially DHCPD is empty; I have no idea how to configure it manually. All my attempts here failed.

lspci shows my network devices:
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
03:00.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)

iwlist wlan0 scanning (when online, doesn't work offline):
wlan0     Scan completed :
          Cell 01 - Address: 00:1D:7E:BC:C6:F4
                    ESSID:"linksys"
                    Mode:Master
                    Channel:11
                    Frequency:2.462 GHz (Channel 11)
                    Quality=48/100  Signal level:-70 dBm
                    Encryption key:on
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : TKIP
                        Authentication Suites (1) : PSK
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
                              12 Mb/s; 48 Mb/s
                    Extra:tsf=0000010f49b5018a
                    Extra: Last beacon: 42ms ago

ifconfig:
wlan0     Link encap:Ethernet  HWaddr 00:02:44:AF:65:51
          inet addr:192.168.1.101  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::202:44ff:feaf:6551/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2233 (2.1 KiB)  TX bytes:5772 (5.6 KiB)

iwconfig:
wlan0     IEEE 802.11bg  ESSID:"linksys"
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:1D:7E:BC:C6:F4
          Bit Rate=1 Mb/s   Tx-Power=24 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Power Management:off
          Link Quality=69/100  Signal level:-62 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

So, overall I think there are two bugs here: DHCP not working and NetworkManager storing and displaying hashed keys instead of the actual key.
Comment 28 Dainius 'GreatEmerald' 2009-05-10 16:42:24 EDT
I've just downloaded a Live CD of Xubuntu (Jaunty Jackalope) to check what is distro-specific. And yes, it seems that it's exactly what I thought: this bug is actually two separate bugs. Xubuntu's NetworkManager-gnome has a fully working DHCP connection - in its connection options all you need to enter is SSID and the key (not sure why it doesn't add SSID automatically there though). So DHCP is the first problem, which is obviously only fedora-specific.
The second problem is speed and reliability. Strangely, the speed is simply not set correctly, and a fix is pathetically easy. In a Terminal, you need to write this:

ifconfig wlan0 up
iwconfig wlan0 rate 56M

And that fixes the speed problem, I think on both Fedora and Xubuntu. This issue is obviously NetworkManager-related, it should find the right rate automatically.

And the reliability issue remains - the card tends to disconnect at times, and then attempt to reconnect. I haven't found a fix for this yet, so I'm not sure what is the cause, too.
Comment 29 Brent R Brian 2009-05-11 06:42:51 EDT
I have two other PCMCIA wireless cards that work fine with NetworkManager and DHCP under F10.

The rt2500pci worked fine until a kernel update, the offending kernel has been identified and the developer has the data.

..."And that fixes the speed problem, I think on both Fedora and Xubuntu. This
issue is obviously NetworkManager-related, it should find the right rate
automatically."...

would it be possible to get you to test the speed change on Fedora ...
Comment 30 Dainius 'GreatEmerald' 2009-05-15 16:19:56 EDT
I've tested it with a Live CD (couldn't make Konqueror resolve URLs, but it just seems it needs it installed for that), and yes, that method works in Fedora 10 too. Although one correction, it should be like this:

ifconfig wlan0 up
iwconfig wlan0 rate 54M

As there is no speed of 56M. You will also need to either make the changes permanent (or else you'll have to reset it each time you launch your PC) by either putting both lines to the /etc/rc.local file or adding "fixed" at the end of the last command (didn't check this method, though):

ifconfig wlan0 up
iwconfig wlan0 rate 54M fixed
Comment 31 Dainius 'GreatEmerald' 2009-06-08 15:12:21 EDT
Finally I managed to solve all the internet problems! And it really seems to be three separate bugs! Here is the solution for the last bug, where internet would randomly drop connection:

http://www.mikegerwitz.com/2008/10/15/ralink-wireless-random-disconnects-no-proberesp/

This guide is only for Gentoo and Ubuntu, but something similar should work with Fedora as well. This bug is in the kernel itself - the system doesn't monitor the connection as long as it should, thus often declaring it dead. With a simple change in one file, the bug is solved! However, that means that you have to compile your own kernel, and there will be no auto updates for it.

So, to sum up, the three bugs in Fedora are:
1. Unknown cause - DHCP failure. The system doesn't acquire IPs like it should, making it possible to connect to the internet only by manually entering all the data and thus setting a static local IP. This is the only bug that is Fedora-specific.
2. iwconfig - wrong bitrate set. This is a generic bug, because it seems that auto bitrate always sets it to 1Mbps, which is intolerable. The solution is in the comment #30.
3. kernel - wrong IEEE monitoring interval set. This makes the connection unstable. The solution is higher in this comment.

Hopefully this will help others that are having these issues!
Comment 32 David W. Legg 2009-06-09 15:41:55 EDT
Created attachment 347080 [details]
/var/log/messages featuring NetworkManager and DHCP error messages with RT2500 failure to connect

Just to confirm that this is still a problem with F11 (released today, no updates.)

I have attached the /var/log/messages file so that a kind fixer can see the exact error messages from NetworkManager and DHCP.  Look for wlan0 in the file, of course.

The problem occurs with WEP encryption.
I use a 10 hex digit key.

Can some-one please mark this as F11 as well as F9 and F10? Ta.
Comment 33 Dainius 'GreatEmerald' 2009-06-09 15:57:35 EDT
How many of the three bugs are you getting? I've read that the latest prepatch kernel, 2.6.30-rc8, might solve the problem #3. Can someone confirm or deny this? And what kernel is used in Fedora 11, 2.6.29.4?
Comment 34 David W. Legg 2009-06-09 17:45:01 EDT
I'm getting #1 on F11.
#2 may be there too, but I can't tell because I'm not getting a connection.
Have certainly seen #3, i.e. instability on F9, but not sure about F10 and F11.

To try a later kernel, I would have to rip a PCI rt2500 card out of a machine that my kids use, so may not be able to check symptoms very easily just now.
Comment 35 David W. Legg 2009-06-10 04:33:59 EDT
Fc11 kernel is kernel-PAE-2.6.29.4-167.fc11.i686.rpm
Comment 36 Dainius 'GreatEmerald' 2009-06-16 11:17:57 EDT
I've now tested 2.6.30 kernel, and here are the results: 
1. The POWER LED on the card is now active!
2. Bug #3 is solved!

However, I seem to have overlooked one more bug (yes, this bug is actually FOUR in one!):
4. The connection is unstable not only due to monitoring interval (bug #3; the now fixed bug outputted this into dmesg: "No ProbeResp from current AP"), but it's also unstable because of something else that output this into dmesg: "no probe response from AP - disassociating" and "direct probe to AP timed out".
Solution, which also fixes bug #3 for older kernels and even to some degree bug #2: get and install compat-wireless from this page:
http://wireless.kernel.org/en/users/Download/stable/

So, as you can see, this looks like the ultimate solution that fixes almost all the bugs mentioned here. The only bug left now is #1, and is fedora-specific.
Comment 37 Dainius 'GreatEmerald' 2009-06-16 11:19:54 EDT
Uhh, the highlighter in bugzilla linked to wrong bugs... I meant the subbugs of this bug, #469120.
Comment 38 David W. Legg 2009-06-22 06:26:27 EDT
I think some-one should change this one from F10 to F11.
Comment 39 Anne 2009-06-22 07:20:13 EDT
Still using F10 on the netbook.  By now NM seems more stable, but I still occasionally have the problem of the passphrase not being accepted.  I've no idea why, but doing an ifdown command causes NM to ask again, and this time it works.  This seems to be consistent.  Does that help?
Comment 40 philby john 2009-08-03 05:56:40 EDT
(In reply to comment #39)
> Still using F10 on the netbook.  By now NM seems more stable, but I still
> occasionally have the problem of the passphrase not being accepted.

Its lost that stability again now with...

NetworkManager-0.7.1-1.fc10.i386
NetworkManager-gnome-0.7.1-1.fc10.i386
2.6.27.25-170.2.72.fc10.i686
Atheros Communication Inc. AR242x 802.11abg Wireless PCI Express Adapter on a Toshiba Satellite A215
AP: Netgear
Error:  wlan0: disassociating by local choice (reason=3)

FC10 pops up "Wireless Network Authentication required" dialogue repeatedly and if it does succeed by other means would show 0% signal strength.
Comment 41 philby john 2009-08-08 14:58:20 EDT
Confirming that the problem is confined to NetworkManager-0.7.1-1.fc10.i386. Uninstalling NetworkManager and installing knetworkmanager won't do cause the latter is dependent on the former. So people please *VOTE* to increase severity of the bug so that this may get resolved ASAP.

With knetworkmanager, we get the same error on an FC10 2.6.27.29-170.2.78.fc10.i686

wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: disassociating by local choice (reason=3)
Comment 42 Christian Nolte 2009-09-11 15:14:27 EDT
With the current F11 kernel update to

  kernel-PAE-2.6.30.5-43.fc11.i686

I cannot get a WLAN connection anymore, so the problem got worse for me. 

Going back to 

  kernel-PAE-2.6.29.6-217.2.16.fc11.i686

solves the problem for me (note that I too have to make several connection retries and sometimes I have also to reconnect my USB stick to get a wireless connection)

I am also using the following:

  NetworkManager-0.7.1-8.git20090708.fc11.i586

Bus 001 Device 004: ID 0846:4260 NetGear, Inc. WG111v3 54 Mbps Wireless [realtek RTL8187B]
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0846 NetGear, Inc.
  idProduct          0x4260 WG111v3 54 Mbps Wireless [realtek RTL8187B]
  bcdDevice            2.00
  iManufacturer           1 Manufacturer_NETGEAR
  iProduct                2 NETGEAR WG111v3
  iSerial                 3 001E2AC1E6C1
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           81
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4 Wireless Network Card
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           9
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              2 NETGEAR WG111v3
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x06  EP 6 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x07  EP 7 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x89  EP 9 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0a  EP 10 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0b  EP 11 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0c  EP 12 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)
Comment 43 David W. Legg 2009-10-28 17:00:00 EDT
Problem still present in F12 beta i386.
Comment 44 David W. Legg 2009-10-29 09:05:52 EDT
This bug affects rt2500 wireless cards and is all about them.
It is also now in Fedora 12.
I cannot see what INFO is needed, so am ticking the info box.

Please would somebody
a) improve the title so that it includes all the Fedoras from 8 through to 12, and
b) improve the title so that it says rt2500 or Ralink or similar.
Ta.
Comment 45 philby john 2009-10-30 05:47:58 EDT
(In reply to comment #44)
> This bug affects rt2500 wireless cards and is all about them.
All about them? The problem is seem in numerous other cards and is not confined to rt2500.

> It is also now in Fedora 12.
> I cannot see what INFO is needed, so am ticking the info box.
> 
> Please would somebody
> a) improve the title so that it includes all the Fedoras from 8 through to 12,
> and

Good idea.

> b) improve the title so that it says rt2500 or Ralink or similar.

Should stay clear of any particularism cause of the concern that others might get ignored when a fix is found for a specific hardware.
Comment 46 Dan Williams 2009-11-02 12:47:24 EST
Can people respond with the kernel version causing the issue, and the specific piece of wlan hardware they have the issue with?  All that's somewhat buried in the comments above, and you may have updated your kernel since you posted the comment.  Thanks!
Comment 47 David W. Legg 2009-11-02 14:30:48 EST
All the kernels in F8, F9, F10, F11 and F12beta that I have tried are involved with this bug except for the very first F8 kernel.  I can probably get the version numbers, but its lots of different versions continually from F8 to F12 as far as I can tell.

Hardware affected = rt2500 pci and rt2500 PCMCIA.
Comment 48 Christian Nolte 2009-11-08 13:18:19 EST
Regarding the affected hardware: again, I have a 

usb 1-9: New USB device found, idVendor=0846, idProduct=4260
usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-9: Product: NETGEAR WG111v3
usb 1-9: Manufacturer: Manufacturer_NETGEAR
usb 1-9: SerialNumber: 001E2AC1E6C1
usb 1-9: configuration #1 chosen from 1 choice

which is a realtek RTL8187B according to lsusb.

The latest kernel which works for me is

2.6.29.6-217.2.8.fc11.i686.PAE

With every other kernel since then, I cannot establish a connection, no matter what I do. By using any newer kernel even the 'trick' with pluging the USB-device out and back in does not work for me.
Comment 49 philby john 2009-11-09 05:38:10 EST
(In reply to comment #48)
> Regarding the affected hardware: again, I have a 
> 
> usb 1-9: New USB device found, idVendor=0846, idProduct=4260
> usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-9: Product: NETGEAR WG111v3
> usb 1-9: Manufacturer: Manufacturer_NETGEAR
> usb 1-9: SerialNumber: 001E2AC1E6C1
> usb 1-9: configuration #1 chosen from 1 choice
> 
> which is a realtek RTL8187B according to lsusb.
> 
> The latest kernel which works for me is
> 
> 2.6.29.6-217.2.8.fc11.i686.PAE

Wow! that's cool info, this is a regression. Now if only someone could bisect and find the faulty commit ;-)
Comment 50 Christian Nolte 2009-11-09 09:34:03 EST
It would be even cooler if someone could confirm this with similar hardware ;)
Comment 51 Dan Williams 2009-11-10 18:57:23 EST
Just for reference:

2.6.30.9-96.fc11.x86_64

works fine with rt73usb.
Comment 52 Bug Zapper 2009-11-18 03:42:05 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 53 Dainius 'GreatEmerald' 2009-11-18 05:43:56 EST
Someone should bump this to version 12 and change the title to reflect the change.
However, the only Fedora-specific bug here for me is DHCP not working properly. Others are NetworkManager and Kernel specific and can be worked around.
Comment 54 David W. Legg 2009-11-18 09:05:55 EST
Definitely affects F11, F12 and Rawhide.
Comment 55 Dan Williams 2009-11-18 16:01:16 EST
*** Bug 472183 has been marked as a duplicate of this bug. ***
Comment 56 cornel panceac 2009-11-27 15:14:33 EST
i can confirm the bug is present in updated f12 with internal pci card 10ec:8172 (realtek), using w2k drivers with ndiswrapper
Comment 57 Rogerio Luz Coelho 2010-04-02 20:56:48 EDT
Ok so I am looking for this message I get when I try to connect to wireless: 

[  127.228213] wlan0: deauthenticating from 00:21:04:1a:21:f6 by local choice (reason=3)

And I found your bug ... I followed the discussion BUT I have something to add: 

I am using WICD , no NetworkManager whatsoever, I am using a Debian Testing machine with kernel 2.6.32 , this error was reproductible in Mandriva 2010.0 64bit , Ubuntu 9.10 64bit and Debian 64bit

My card is a Realtek rtl8187b internal USB

Works fine in MS-Win , but has a STRANGE bahavior in Linux. 

Have a post on LinuxQuestions.org about my problem with all the logs: 

http://www.linuxquestions.org/questions/linux-laptop-netbook-25/wireless-rtl-8187b-wicd-wpa_supplicant-naughty-behaviour-799377/

Thanks for letting me know I am not insane :)  

Rogerio
Comment 58 Paulo Henrrique 2010-07-07 17:49:26 EDT
I had the same problem but i solved just deleting the files "ifup-wlan0" of my
system and after my network card has worked.

The files i found at directories:

/etc/sysconfig/network-scripts/ifup-wlan0

/etc/sysconfig/networking/devices/ifup-wlan0

/etc/sysconfig/networking/profiles/default/ifup-wlan0.


I think the same should solve problem with other cards..
Comment 59 Stanislaw Gruszka 2010-10-01 13:25:09 EDT
This bug report contains too many comments describing different problems. Please open separate bug reports for rt2500 and rtl8xxx hardware, against current fedora kernels (but only if you have kernel/driver problem, for example comment 58 does not describe kernel problem).
Comment 60 cornel panceac 2010-10-01 14:29:42 EDT
afaict, in recent f13 kernels, rt2500 works.
Comment 61 philby john 2010-10-06 08:28:47 EDT
For the Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter, I have long stopped using WAP and have configured my WiFi router to use WPA Personal/WPA2-Personal for configuration. Now works fine with these settings.

Note You need to log in before you can comment on or make changes to this bug.