Description of problem: Since updating to kernel 3.6.x wlan won't work correctly, on my system the ssid of the wlan-network is missing. While plugging wlan stick (RTL8188S) it seems to start, but iwconfig tells me that it is unassociated. The module for the stick is r8712u. I can't find any other error messages. Before updating it work on kernel 3.5.1 Version-Release number of selected component (if applicable): kernel-3.6.3-1.fc17.x86_64 staging-kmod-addons-3.6.1-1.fc17.x86_64 kmod-staging-3.6.3-1.fc17.x86_64-3.6.1-1.fc17.3.x86_64 How reproducible: Steps to Reproduce: 1. unplug stick 2. plug in stick 3. Actual results: Expected results: Additional info:
staging mods are removed, but nothing changed
Without the staging mods, there is no driver for your device. With them, I can't really help you, since they aren't part of Fedora itself. My apologies...
Hmm...i just tried it with kernel-3.4.5-2.fc17.x86_64, without staging module, and everything is fine. What happened that the older kernel supports the device and the newer kernel doesn't?
What is the output from 'ethtool -i wlan0'?
# ethtool -i wlan0 driver: r8712u version: firmware-version: bus-info: 1-2:1.0 supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no the output is equal on all kernel versions iwconfig on kernel 3.4.5-2.fc17.x86_64 delivers wlan0 IEEE 802.11bg ESSID:"xxxxxx.adhoc" Nickname:"rtl_wifi" Mode:Ad-Hoc Cell: xx:xx:xx:xx:xx:xx Bit Rate:54 Mb/s Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xx Security mode:xxxx 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 wlan is working perfectly with the older kernel version
Ah, I forgot that we had enabled that particular staging driver... Hopefully Larry will have some input?
The only changes to r8712u in kernels 3.6.x were for fixing bugs. None of them should affect association. I am currently using my D-Link DWA-130, which is driven by r8712u with kernel 3.7-rc2 from wireless-testing. It also worked with kernel 3.6. There was a reversion of the latest firmware change as it failed with certain devices. Perhaps yours is one of them. Please post the output of the command 'md5sum /lib/firmware/rtlwifi/rtl8712u.bin'. I would also like to see the section of the dmesg output where the device tries to associate. It might be best to post the entire output as an attachment.
Created attachment 635719 [details] output from md5sum ... the attachment is sent
Why is the "link not ready"? If the firmware is loaded, the device should be ready.
Created attachment 635942 [details] output while using 3.6.x that's correct larry...but it is still unassociated on 3.6.x that is the reason while i wrote here...i will have a try on 3.5.x which is still on my system maybe something relevant changed from 3.5.x to 3.6.x
on 3.5.1-1.fc17.x86_64 everything is fine and wlan is working...so there have to be something changed from 3.5.x to 3.6.x the message that wlan is not ready is still there but i think it only has to do with IPv6 cause i have disabled that
Please excuse the verbosity, but I would like to confirm the breakdown of the r8712u driver with the latest kernel-3.6.3-1.fc17.i686.PAE. This morning I received a frantic phone call from my brother in rural Umbria, Italy. I attempt to maintain his Fedora 17 system, that I installed on a recent visit, via an ipsec tunnel from here in SW North Carolina. I had done a yum update which installed this new kernel, and when he rebooted, his wireless connection failed to start. On an educated hunch, I asked him to reboot the older 3.5.4-2.fc17.i686.PAE kernel. Sure enough, the wireless connection came up and worked as perfectly as before. This is with a Rosewill RNX-N180UBE 802.11 b/g/n wireless adapter, identified by lsusb as: Bus 001 Device 003: ID 0bda:8172 Realtek Semiconductor Corp. RTL8191SU 802.11n WLAN Adapter which uses the r8712u staging module. The hunch came from my similar experience with my mythtv machine - a quad processor AMD Phenom(tm) II X4 945 Processor with the same Rosewill USB wireless adapter. This setup had been working perfectly; in fact, it was because of this success that I set up the 802.11n network for my brother in Italy last summer. But when a yum update introduced kernel-3.6.3-1.fc17.x86_64, the wireless connection stopped working. Reverting to the previous kernel-3.6.2-4.fc17.x86_64 fixed it. This additional problem was the final straw in a horrific string of instabilities introduced in F16 and F17. I judged these incompatible with my mythtv needs and converted that machine to Centos 6.3. Sadly the r8712u staging driver isn't available in Centos and I've had to revert to an ancient D-Link DWL-G122 802.11b adapter. But wait! There's more! I have another 64 bit quad processor machine, an AMD Phenom II, also using the same Rosewill USB wireless adapter, that's running kernel-3.6.3-1.fc17.x86_64 perfectly, with the r8712u module. Why would the r8712u module with kernel 3.6.3-1 fail on two machines, but work perfectly on a third machine? I'm baffled. I would be happy to try to help debug this puzzle if I can. Maybe there's a clue in the working system. My two non-working systems are a bit inaccessible, however.
I have no idea why r8712u fails in kernel-3.6.3. The driver works with kernels 3.5.X, 3.5.X, and 3.7-rcX on my system; however, it is openSUSE, not Fedora. Thus far, no one has produces any log output that suggests a cause for the problem.
Logs! You want logs? I've fired up the Fedora 16 where r8712u is failing and collected some info, maybe even useful info - who knows. There's dmesg - the whole thing - because I don't know what would be lost if I truncated it. Also ifconfig and iwconfig. Also /var/log messages while I yanked and reinserted the adapter. I hope this is useful...
Created attachment 640305 [details] Logs and dmesg from failed wireless r8712u
The logs are totally useless. There is no information about why the failure occurs. Do you use NetworkManager? If so, /var/log/NetworkManager would be useful.
I was able to clear off a partition on my disk and booted the Fedora 17 Live CD. That OS was able to connect using my D-Link DWA-130, which uses r8712u. I then installed it and let it upgrade. At this point I had a kernel of 3.6.5-1.f17.x86_64. Upon rebooting, the command 'sudo iwlist scan' yielded nothing because the network was down. A simple 'sudo ifconfig wlan0 up' cleared that problem, and I could then connect to a WPA2 802.11n network. I then plugged in my Rosewill RNX-N180UBE, and it worked. Sorry, I am unable to duplicate the results, even though I did my best to duplicate your setup.
On my system NetworkManager isn't even installed. For now i downgraded kernel to 3.5.1-1 and everything is fine, i just have tried 3.6.5 but it doesn't worked. Therefore i believe something have changed from 3.5.x to 3.6.x
If any of these reports are using the initscripts network service rather than NetworkManager and failing to set ESSID after upgrade to kernel 3.6, they may be caused by initscripts bug #875328.
I confirm that r8712u failed to connect using the network service, but connects fine with NetworkManager. That's sad. However, Paul Jenner gives the good news that a fixed initscripts-9.34.4-1.fc16 is on the way. I will await this with great anticipation. Lord, spare us from any more "improvements".
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. 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.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.