iwconfig bitrate is not set properly

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

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)

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.

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.

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 Met...

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

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.

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.

I think this one ought to be "high" severity because some systems are completely unable to connect to networks.

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 :)

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?

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?

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.

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.

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.

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.

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)

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?

bug 457441 is tracking rt2500 problems for those of you interested

(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.

I have also seen the corrupted HEX KEY when "show key" is clicked using rt2500pci

(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?

WEP HEX

0x00112233445566778899AABBCC

13 hex digits

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.

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.

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!

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.

:>

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 re...

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.

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 ...

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

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!

Created attachment 347080
/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.

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?

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.

Fc11 kernel is kernel-PAE-2.6.29.4-167.fc11.i686.rpm

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.

Uhh, the highlighter in bugzilla linked to wrong bugs... I meant the subbugs of this bug, #469120.

I think some-one should change this one from F10 to F11.

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?

(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.

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)

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
          Usag...

Problem still present in F12 beta i386.

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.

(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.

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!

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.

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.

(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 ;-)

It would be even cooler if someone could confirm this with similar hardware ;)

Just for reference:

2.6.30.9-96.fc11.x86_64

works fine with rt73usb.

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

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.

Definitely affects F11, F12 and Rawhide.

*** Bug 472183 has been marked as a duplicate of this bug. ***

i can confirm the bug is present in updated f12 with internal pci card 10ec:8172 (realtek), using w2k drivers with ndiswrapper

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

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..

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).

afaict, in recent f13 kernels, rt2500 works.

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.