drivers - Linux will not activate wireless after device has been re-enabled

20
2014-04
  • XHR

    Using a Eee 900A netbook by Asus. By pressing Fn + F2, I can disable or enable the wireless chip on the netbook, a blue LED indicates the status. I've been able to connect to wireless networks just fine with this netbook. However, if the wireless chip ever becomes disabled, I have to reboot to get my network connection back. This generally happens when suspending. For some reason the LED will be off and I have to hit Fn + F2 for it to light up again. However, after doing so, Linux will not reconnect to the network. It simply changes the wireless status from "wireless is disabled" to "device not ready". Even worse, I've recently had issues with the chip being enabled at boot, thus making it nearly impossible to get connected.

    I've searched around on-line but haven't found much of anything useful on this. This happens on all kinds of different distros including Ubuntu 9.10 Netbook, EeeBuntu 4 beta, Jolicloud and Ubuntu 10.04 Netbook.

    Edit

    I noticed this question is getting a lot of views. To give a quick update, I never did resolve this issue with the given distro's. However, I'm currently running Ubuntu 10.10 netbook edition and this issue has gone away.

  • Answers
  • BradChesney79

    I can confirm that WICD (in Ubuntu community repos: add community/universe repos in sources then apt-get install wicd) does recover from sleep and hibernate with Wireless Networking working more often than not on my machine. --But, it is not 100%, thus my visit to this web page. Pertinent details: Kubuntu 12.04 64-bit, Intel Core2 Duo, Intel 3945ABG.

    The first thing I do on a new *buntu/Debian install is get rid of the stock networking utility and install WICD...

  • Ignacio Vazquez-Abrams

    Sounds like a problem with the wifi module. A rmmod followed by a modprobe of the relevant module should fix it, but you may need to shut down NetworkManager first in order to be able to remove the module. Don't forget to report this issue in Launchpad.

  • dag729

    In my experience, almost all of the network problems was caused by NetworkManager: can you try to remove it, configure manually your connections and then try again to start/stop the wifi? If it works, just purge Network Manager.

  • Amos M. Carpenter

    For anyone still encountering this problem, I've found that using WICD instead of the default NetworkManager tends to be more reliable. I sometimes had NetworkManager continuously trying but failing to get a connection to my router (for no reason I could think of, other devices connected just fine), while WICD didn't seem to have a problem doing that. I haven't updated for a couple of distro's, though, so perhaps this has been fixed in more recent versions of NetworkManager.

  • oKtosiTe

    Did you install using an "alternate" installation medium?
    On my Eee PC 701, the alternate installer left behind a hard-configured /etc/network/interfaces, which prevented NetworkManager from automatically configuring the interface.

    Commenting out the wlan0 entry in said configuration file did the trick for me:

    #auto wlan0
    #iface wlan0 inet dhcp
    

  • Related Question

    drivers - DPC latency spikes every 60 seconds related to Dell 1515 (atheros) WLAN
  • user3000

    I'm getting DPC latency spikes every 60 seconds related to Dell 1515 (atheros) WLAN. If you turn off the wireless card, the spikes go away. If you disable wireless autodiscovery, they go away. I've seen a blog post with a script to disable autodiscovery while you are connected, then you have to run anotehr script to eable autodiscovery again when you disconnect. That didn't work for me, and I really want a real fix, not a workaround.

    These spikes often cause network dropouts, sound dropouts or video freezes.

    Suggestions?

    I am running Windows Server 2008 on this laptop. Also tried dualbooting with Windows 7 (default drivers) - same issue.


  • Related Answers
  • mas

    I'm assuming that your reference to DPC implies this is on a Windows platform.

    The page documenting Thesycon's DPC Latency Checker Tool http://www.thesycon.de/deu/latency_check.shtml has the following good advice when the driver responsible for DPC latency spikes has been identified:

    When you have identified the device driver which is responsible for the drop-outs consult the device vendor's Web site or customer support to find an update for this driver. If this is not possible you may decide to keep the concerned device disabled while you are using streaming applications.

    Clearly, if you must receive the stream via the wireless driver then disabling it is not possible though I'm not clear from your question whether you can just disable autodiscovery and still successfully use the card to receive the stream. Whilst this is a workround it may be the best compromise until the driver is fixed, if it can be. As the Thesycon page points out:

    Processing of streaming data in real-time is a very challenging task for Windows based applications and device drivers. This is because by design Windows is not a real-time operating system. There is no guarantee that certain (periodic) actions can be executed in a timely manner. ...

    If you have not already looked at Thesycon's DPC Latency Checker Tool and your project is on one of its supported platforms and is non-commercial then you consider using it for free to confirm your conclusions. Details of the tool and next steps are in the page hyperlinked above.

    One final, obvious, suggestion is to relieve the PC of other work by not running unnecessary processes and ensuring sufficient free RAM may help.