0846:6a00 mac80211: WLAN losing connection: No ProbeResp

[Frank Niedermann]

Ubuntu 8.10 alpha 6 is loosing wireless network connection after some time of usage.

Message in /var/log/syslog:

Mar 10 05:58:56 mediapc kernel: [ 460.459587] wlan0: No ProbeResp from
current AP 00:1b:2f:59:9a:14 - assume out of range
Mar 10 05:58:56 mediapc NetworkManager: <info> Supplicant state changed: 0

Computer has to reboot in order to get a connection again. Disconnection happens after different times, sometimes after a minute, sometimes after 20 minutes.

There are some reports in ubuntuforums.org about this also: http://ubuntuforums.org/search.php?searchid=37603879 <- This link doesn't work

Frank

This bug is related to mac80211 and occurs with several different wireless network interface cards.
// Erik

[Alexander Sack (asac)]

please tell us the wifi chip you are using (e.g. attach output of lspci -v) and your complete /var/log/syslog _after_ a failed connect attempt.

Thanks,
 - Alexander

[Alexander Sack (asac)]

this is a driver bug. once we know the used driver/chipset we should reassign this accordingly.

[Frank Niedermann (fbn)]

Hi,

I've attached the output of lsusb -v. It's a NetGear, Inc. WG111 WiFi (v2) USB WLAN stick using the module rtl8187:
usbcore 145516 7 lirc_mceusb2,rtl8187,usb_storage,libusual,ehci_hcd,uhci_hcd

[Brian Murray (brian-murray)]

Please include as attachments the following additional information, if you have not already done so (please pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command 'uname -a' in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command 'dmesg > dmesg.log' and attach the resulting file 'dmesg.log' to this bug report.
3. Please run the command 'sudo lspci -vvnn > lspci-vvnn.log' and attach the resulting file 'lspci-vvnn.log' to this bug report.
For your reference, the full description of procedures for kernel-related bug reports is available at https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks in advance!

[Frank Niedermann (fbn)]

Hi,

uname -a: Linux mediapc 2.6.24-11-generic #1 SMP Fri Feb 29 22:08:31 UTC 2008 i686 GNU/Linux

And dmesg.log attached

[Frank Niedermann (fbn)]

and lspci

[Brian Murray (brian-murray)]

There is actually an updated kernel available so if you could test with that it would be quite helpful. Additionally, I don't see the error in the dmesg log file you have attached. Could you add a full dmesg file that contains the error after updating? Thanks again.

[Henning Kulander (hennikul-linpro)]

I installed 8.04 this weekend on a newly upgraded machine with an ASUS P5k Premium motherboard. It has a built in rtl8187 wireless adapter.

Since the install I have experienced the same problem several times:
[ 3276.773769] wlan0: No ProbeResp from current AP 00:18:f8:fb:cf:64 - assume out of range

Other equipment remain connected and a reboot fixes the problem. The last time I tried everything from restarting networking to killing wpa_supplicant and restarting wpa-ifupdown. The thing that seemed to do the trick was to run wpa-ifupdown stop and then start again. restart or force-reload did not seem to help.

[Pavlik (pavel-kup)]

This problem seems to be similar to bug #182473. And it is very annoying. It actuallt prevents me from using Ubuntu. :(

[Brian Murray (brian-murray)]

Could you please add the full output of 'dmesg' after booting and experiencing the problem as an attachment to your bug report? Thanks in advance.

[Frank Niedermann (fbn)]

Hi,

my hardware got replaced, so I can not provide further information. Maybe somebody else with the same problem can take over? Otherwise I think the bug should be closed or something.

Thanks,
  Frank

[JoshuaPurcell (joshua-purcell)]

I'm having the same issue. Here's uname -a:
Linux laptop 2.6.22-14-generic #1 SMP Tue Feb 12 02:46:46 UTC 2008 x86_64 GNU/Linux

Attached is the output from lspci -vvnn. Also I'll post the output of dmesg after the problem has occurred (and I have reloaded the kernel module). This problem happens all the time on my laptop (anywhere from 2-3 times/hour), and it is always fixed by doing this:
    sudo killall NetworkManager
    sudo modprobe -r iwl4965
    sleep 2
    sudo modprobe iwl4965
    sudo NetworkManager

I'll attach my dmesg from just after startup if necessary. Thanks for any help.

[JoshuaPurcell (joshua-purcell)]

dmesg output after problem has occurred (see previous post for more information).

[JoshuaPurcell (joshua-purcell)]

Sorry about multiple posts in a row, but I found this link that may be helpful in solving the issue:
http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=29255

In the first post of that thread, the guy poster says that he solves the problem by doing the following:
At moment i've raised the value of IEEE80211_MONITORING_INTERVAL in ieee80211/ieee80211_sta.c file.

#define IEEE80211_MONITORING_INTERVAL (1000 * HZ)

[jan (jan-ubuntu-h-i-s)]

I think that the main problem here is NetworkManager.
I don't mind that after a while of no signal, the network is disconnected.
However, the system should be able to recover from this gracefully, and retry once proper signal is available again.
I think this is what is really broken in Hardy now, apart from the other rt bugs (see eg. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/190515 )

Note that going to a non-beacon mode would fix the problem in a way JoshuaPurcell describes.
https://answers.launchpad.net/ubuntu/+question/5525

My adapter:
RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01) / Subsystem: Linksys WMP54G 2.0 PCI Adapter

[jan (jan-ubuntu-h-i-s)]

I should also have referred to a separate bug report I filed for this:
https://bugs.launchpad.net/ubuntu/+bug/226601

[egaudrain (et-gaudrain)]

I'm having the same problem with Ubuntu 2.6.24-16.30-server using rt2500. I get the "No ProbeResp from current AP 00:1c:26:7b:51:70 - assume out of range" message after a random number of hours. Here are the logs. Tell me if you need another one.

[egaudrain (et-gaudrain)]

The problem appears several time in this long log, but you can find it at line 1485.

[egaudrain (et-gaudrain)]

Oh, and as you will notice, I do not use rt18187 but rt2500 module. Then it does not seem to be such a specific problem.

Cheers,
-Etienne

[Mike (insomniux)]

Hi,
Same annoying problem here on a new desktop with a newly installed Ubuntu 8.04 (details below).
When I boot, the network comes up without a problem, but it is quite slow, as compared with my wireless laptop (factor 5-10 slower). After some time (variable duration) suddenly the connection is dropped and the message "[ 1612.220846] wlan0: No ProbeResp from current AP 00:18:4d:36:bc:c5 - assume out of range" appears in dmesg. When I stop the network and restart it again the connection is reestablished.
Any options to get rid of this bug?
Thanks
Mike

============ system
Fresh installation of Ubuntu 8.04 64-bit on 13-6-2008
Linux maud-desktop 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/Linux

============ hardware
root@maud-desktop:/home/mike# lshw -C system
maud-desktop
    description: Desktop Computer
    product: GA-MA69G-S3H
    vendor: Gigabyte Technology Co., Ltd.
    width: 32 bits
    capabilities: smbios-2.4 dmi-2.4 smp-1.4 smp
    configuration: boot=normal chassis=desktop cpus=0 uuid=4E2F4100-0000-0000-0000-00007DAAE342
root@maud-desktop:/home/mike# lshw -C processor
  *-cpu
       description: CPU
       product: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
       vendor: Advanced Micro Devices [AMD]
       physical id: 4
       bus info: cpu@0
       version: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
       slot: Socket M2
       size: 2600MHz
       capacity: 3200MHz
       width: 64 bits
       clock: 200MHz
       capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp x86-64 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch cpufreq
r
root@maud-desktop:/home/mike# lshw -C network
  *-network
       description: Wireless interface
       product: RT2561/RT61 802.11g PCI
       vendor: RaLink
       physical id: 6
       bus info: pci@0000:02:06.0
       logical name: wmaster0
       version: 00
       serial: 00:1e:e5:2a:03:35
       width: 32 bits
       clock: 33MHz
       capabilities: pm bus_master cap_list logical ethernet physical wireless
       configuration: broadcast=yes driver=rt61pci ip=192.168.2.30 latency=32 module=rt61pci multicast=yes wireless=IEEE 802.11g

============ lspci
mike@maud-desktop:~$ lspci
00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge
00:02.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Graphics Port 0)
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2)
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14)
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia
00:14.3 ...

[Mike (insomniux)]

Hi,
While experimenting I finally found out that the command
"iwconfig wlan0 retry 14"
kind of solved the problem. The initial value was 7. I've not tried any other values.
The problem is reproducible by switching between the two values. Furthermore I noticed that the transfer speed was significantly influenced by the signal strength. Even at high signal levels (>80%) My laptop usually has a signal strength lower than 60%, but usually has a higher transfer rate. So I've the impression this finally could be a hardware problem rather than a software bug.
Hope this solution may help others as well.
Mike

[Balaji (balaji-ramasubramanian)]

I find the same problem persisting in Ubuntu 8.04. If this is percolating to version 8.10, I would be worried about it.

Can you please quickly help with a fix for this problem?

-Balaji

[Balaji (balaji-ramasubramanian)]

dmesg.log

[Balaji (balaji-ramasubramanian)]

version.log

[Balaji (balaji-ramasubramanian)]

Please use the above four logs to give me an update of this bug and its fix.

[jeff (jmacfar)]

I'll go ahead and add my stuff to this bug as well.

While googling, noticed a post on lkml.org about how some guy added a hack to the mac80211 layer that kept him online, though it still reported the "Assume out of range" message. Anyway, here's the attachments.

WG111 (v1) p54usb driver.

As opposed to others here, I get about 5 minutes of connection time, then it goes to zero. Sometimes unplug/replug gets me a few more minutes. Most of the time, not.

[Erik Andrén (erik-andren)]

I can confirm this bug using Intrepid Alpha 4 and an iw4965 wireless NIC

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Mike Gerwitz (mikegerwitz)]

I am not using Ubuntu (Gentoo, vanilla sources, kernel 2.6.27), however I'm having the same problem, so hopefully this information will help.

I do not use NetworkManager (it didn't handle my wireless properly), so that is not the problem. I searched the driver source for the phrase, but could not find it anywhere - does anyone know where this error message originates?

grep -rl "ProbeResp" ./

I used the above command to locate any strings within all files in the source directory and found nothing of use. However, using the above command to search for "No ProbeResp" in the kernel source directory (2.6.27) produced the following file, in which I found the error message:

/usr/src/linux/net/mac80211/mlme.c (line 1059)

Above, the following link was referenced:

http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=2081&p=30312&hilit=No+ProbeResp+from+current+AP#p30312

However, the file it references does not appear to exist within kernel 2.6.27. The file you are looking for to modify IEEE80211_MONITORING_INTERVAL is the above file (mlme.c). This is the constant that is referenced when a timeout is determined. I'll set it to a higher value (default seems to be "2 * HZ"), recompile, and post back with any success. Either way, it'll only be a temporary fix - we'll need to take it up with serialmonkey to figure out the real problem. Hope this helps.

I use the driver rt61pci

======= dmesg | tail
[41884.647257] wlan0: authenticate with AP 00:15:e9:76:1a:ee
[41884.658208] wlan0: authenticated
[41884.658208] wlan0: associate with AP 00:15:e9:76:1a:ee
[41884.668257] wlan0: RX ReassocResp from 00:15:e9:76:1a:ee (capab=0x431 status=0 aid=5)
[41884.668257] wlan0: associated
[41892.844239] wlan0: no IPv6 routers present
[68822.729255] wlan0: No ProbeResp from current AP 00:15:e9:76:1a:ee - assume out of range
=======

======= lspci | grep RT
01:07.0 Network controller: RaLink RT2561/RT61 802.11g PCI
=======

======= uname -a
Linux mikegerwitz-pc 2.6.27-rc4-mikegerwitz #1 SMP Sat Aug 30 20:39:45 EDT 2008 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5400+ AuthenticAMD GNU/Linux
=======

Wireless works fine until this error occurs, seemingly randomly. This occurs both when the connection is in use and idle. To restart the connection, I sometimes have to remove the kernel module and re-modprobe it, then restart the interface:

=======
$ rmmode rt61pci
$ modprobe rt61pci
$ /etc/init.d/net.wlan0 restart
=======

The connection then works properly again until the next error, as pasted above from dmesg.

[jeff (jmacfar)]

[quote]
However, the file it references does not appear to exist within kernel 2.6.27. The file you are looking for to modify IEEE80211_MONITORING_INTERVAL is the above file (mlme.c). This is the constant that is referenced when a timeout is determined. I'll set it to a higher value (default seems to be "2 * HZ"), recompile, and post back with any success. Either way, it'll only be a temporary fix - we'll need to take it up with serialmonkey to figure out the real problem. Hope this helps.

[/quote]

I've tried this already. Didn't help. I've also tried commenting various parts of mlme.c, and none of it has made a difference.

I was hoping 2.6.27-rc4/rc5 would solve this (there were a few mac80211 association issues fixed), and it helped slightly, but not enough to fix the issue. Now, at least, I can stay associated to an AP for any length of time. But, almost the *instant* any traffic goes over the WG111, the NoProbeResp messages come up and the association is killed, not to be resurrected.

FWIW, an atheros bases pcmcia card (wpc54ag IIRC) works fine with ubuntu kernels and 2.6.27-rc[45].

Will try with the ubuntu 2.6.27 kernel and/or 8.10 Alpha5.

[jeff (jmacfar)]

Alpha 5 does not resolve the issue wrt Linksys WG111. Will open a new bug report.

[Mike Gerwitz (mikegerwitz)]

After attempting what was stated in my previous message (modifying the monitoring interval to "100 * HZ" and recompiling the kernel), I have not received the error. My PC has been on since my last post and my net has not gone down. Speeds are excellent - above what I thought my max was. I see no other problems.

I also noticed that the same error is happening on another computer of mine, where it previously didn't. It may be attributed to a new kernel version (2.6.25, while it was previously using 2.6.24). Therefore, I do not think this problem lies within the rt61* drivers.

It's a good fix until others figure out a more effective solution. Hope it helps everyone else.

[jeff (jmacfar)]

Hmm...well, I didn't move the monitoring interval that high (50x higher). I'm only an armchair developer, but couldn't moving the monitoring interval that high just be compensating for a driver too slow to react and/or just missing beacons left and right?

In any event, I filed a bug against intrepid (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/268835)

I'll try moving the interval to 100*HZ. At the very least, maybe it will keep me online for a bit..

[Balaji (balaji-ramasubramanian)]

Hi,

Btw, can you all please help me in this:

I cannot compile kernels right now. I like using Linux, but I don't want to
use self-compiled kernels right now, unless I become an expert at it. I can
start learning now that I have two laptops, but I'd not waste time on it
with so much research pending. So, will you guys please tell me if your
'fixes' if you have found any, are going to go into the next kernel
distribution? If yes, which one?

Thanks,
Balaji

On Thu, Sep 11, 2008 at 8:25 AM, jeff <email address hidden> wrote:

> Hmm...well, I didn't move the monitoring interval that high (50x
> higher). I'm only an armchair developer, but couldn't moving the
> monitoring interval that high just be compensating for a driver too slow
> to react and/or just missing beacons left and right?
>
> In any event, I filed a bug against intrepid
> (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/268835)
>
> I'll try moving the interval to 100*HZ. At the very least, maybe it will
> keep me online for a bit..
>
> --
> mac80211: WLAN losing connection: No ProbeResp
> https://bugs.launchpad.net/bugs/200500
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Balaji

[Gian (gian-redhat-bugs)]

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.

[Dan (dan-redhat-bugs)]

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!

[Brent (brent-redhat-bugs)]

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.

:>

[Dainius (dainius-redhat-bugs)]

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

[Dainius (dainius-redhat-bugs)]

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.

[Brent (brent-redhat-bugs)]

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

[Dainius (dainius-redhat-bugs)]

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

[Dainius (dainius-redhat-bugs)]

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!

[David (david-redhat-bugs)]

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.

[Dainius (dainius-redhat-bugs)]

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?

[David (david-redhat-bugs)]

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.

[David (david-redhat-bugs)]

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

[Dainius (dainius-redhat-bugs)]

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.

[Dainius (dainius-redhat-bugs)]

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

[David (david-redhat-bugs)]

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

[Anne (anne-redhat-bugs)]

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?

[philby (philby-redhat-bugs)]

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

[philby (philby-redhat-bugs)]

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)

[Christian (christian-redhat-bugs)]

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

[David (david-redhat-bugs)]

Problem still present in F12 beta i386.

[David (david-redhat-bugs)]

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.

[philby (philby-redhat-bugs)]

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

[Dan (dan-redhat-bugs)]

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!

[David (david-redhat-bugs)]

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.

[Christian (christian-redhat-bugs)]

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.

[philby (philby-redhat-bugs)]

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

[Christian (christian-redhat-bugs)]

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

[Dan (dan-redhat-bugs)]

Just for reference:

2.6.30.9-96.fc11.x86_64

works fine with rt73usb.

[Bug (bug-redhat-bugs)]

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

[Dainius (dainius-redhat-bugs)]

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.

[David (david-redhat-bugs)]

Definitely affects F11, F12 and Rawhide.

[Dan (dan-redhat-bugs)]

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

[cornel (cornel-redhat-bugs)]

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

[Rogerio (rogerio-redhat-bugs)]

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

[Paulo (paulo-redhat-bugs)]

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

[Stanislaw (stanislaw-redhat-bugs)]

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

[cornel (cornel-redhat-bugs)]

afaict, in recent f13 kernels, rt2500 works.

[philby (philby-redhat-bugs)]

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.

[penalvch (penalvch)]

No response from OR requested in 2012.

[Ned Bingham (nedb)]

Greetings!

I have to share bad news with you.
Approximately few months ago I have gained access to your devices, which you use for internet browsing.
After that, I have started tracking your internet activities.

Here is the sequence of events:
Some time ago I have purchased access to email accounts from hackers (nowadays, it is quite simple to purchase such thing online).
Obviously, I have easily managed to log in to your email account (<email address hidden>).

One week later, I have already installed Trojan virus to Operating Systems of all the devices that you use to access your email.
In fact, it was not really hard at all (since you were following the links from your inbox emails).
All ingenious is simple. =)

This software provides me with access to all the controllers of your devices (e.g., your microphone, video camera and keyboard).
I have downloaded all your information, data, photos, web browsing history to my servers.
I have access to all your messengers, social networks, emails, chat history and contacts list.
My virus continuously refreshes the signatures (it is driver-based), and hence remains invisible for antivirus software.

Likewise, I guess by now you understand why I have stayed undetected until this letter...

While gathering information about you, I have discovered that you are a big fan of adult websites.
You really love visiting porn websites and watching exciting videos, while enduring an enormous amount of pleasure.
Well, I have managed to record a number of your dirty scenes and montaged a few videos, which show the way you masturbate and reach orgasms.

If you have doubts, I can make a few clicks of my mouse and all your videos will be shared to your friends, colleagues and relatives.
I have also no issue at all to make them available for public access.
I guess, you really don't want that to happen, considering the specificity of the videos you like to watch, (you perfectly know what I mean) it will cause a true catastrophe for you.

Let's settle it this way:
You transfer $1550 USD to me (in bitcoin equivalent according to the exchange rate at the moment of funds transfer), and once the transfer is received, I will delete all this dirty stuff right away.
After that we will forget about each other. I also promise to deactivate and delete all the harmful software from your devices. Trust me, I keep my word.

This is a fair deal and the price is quite low, considering that I have been checking out your profile and traffic for some time by now.
In case, if you don't know how to purchase and transfer the bitcoins - you can use any modern search engine.

Here is my bitcoin wallet: 1665CsfFELrfiiubFZtLsGHGuqbUz1wXcz

You have less than 48 hours from the moment you opened this email (precisely 2 days).

Things you need to avoid from doing:
*Do not reply me (I have created this email inside your inbox and generated the return address).
*Do not try to contact police and other security services. In addition, forget about telling this to you friends. If I discover that (as you can see, it is really not so hard, considering that I control all your systems) - your video will be shared to public right away.
*Don't try to ...