madwifi cannot reconnect after resume from suspend

Bug #271097 has already been reported for NM 0.7 not remembering passwords, so I'm narrowing the scope of this bug to just the resume issue.

Exactly which version of NM do you have installed?

I added the verion.

I looked for a bug-report on NM 0.7 not remembering password, but I didn't find #271097. Thanx for the tip.

On Sat, 2008-09-20 at 07:18 +0000, Thomas Schewe wrote:
> I added the verion.
>
> I looked for a bug-report on NM 0.7 not remembering password, but I
> didn't find #271097. Thanx for the tip.

All further work on this bug will take place in the master bug (271097),
thanks.

I'm sorry, that's as regards the password problem. The suspend/resume issue stays here though.

Is the resume issue only with encrypted networks, or are you also unable to connect to open wifi? Does wired internet work? Can you try the steps listed here? https://wiki.ubuntu.com/DebuggingNetworkManager

I did have the time to set up a non-encrypted wlan or to follow the steps in DebuggingNetworkManager (Do I have to do every step, also the part about crashing?). But I took it as inspiration.

After removing an (re)loading the kernel-module ath_pci it is possible to reconnect to the encrypted wlan.

Possibly it is a problem in madwifi.

Any idea for a workaround?

After changing back to the madwifi-release, which don't have problems with a resume under 8.04, I still have problems with the resume. So I don't think, that it is a problem in madwifi.

After resume, can you connect from the command line without having to unload/reload the driver? You can test this on unencrypted or WEP like this
sudo iwconfig <interface> essid <essid>
or
sudo iwconfig <interface> essid <essid> key <key>

where <interface> is your interface... ath0, eth1, wlan0, etc
<essid> is the network's name, ex: linksys
<key> is the WEP key

followed by running "sudo dhclient" to get an IP address. Can it connect? Check for an IP address with the "ifconfig" command. If it doesn't work from the command line, this is a madwifi bug. If it does work, probably NM.

Due to security-issues I have no unencrypted or WEP-encrypted WLAN in use. So I cannot test this. And in the next few days I will not have the opportunity to set up an additional unencrypted or WEP-encrypted WLAN. (Perhaps I find an open WLAN somewhere on a train-station or so on while I am travelling in the next week.)

Yeah, I'm not dumb enough to have WEP on my network either ;) How about Starbucks? Their network is unencrypted. I'm kind of assuming it's a laptop, not a desktop.

There are not so much Starbuck's in Germany. ;-) And I live in the suburbs of Berlin, where you cannot find so much store with open wifis.

But tomorrow I take the train and perhaps I have enough time to check out wifis on the mainstations of Berlin or Hannover...

I checked it on a open open hotspot:

thosch@betaThoscheee:~$ sudo iwconfig ath0 essid tmobile

Went trough without any comment. The result:

thosch@betaThoscheee:~$ iwconfig
lo no wireless extensions.

eth0 no wireless extensions.

wifi0 no wireless extensions.

ath0 IEEE 802.11g ESSID:"tmobile" Nickname:""
          Mode:Managed Channel:0 Access Point: Not-Associated
          Bit Rate:1 Mb/s Tx-Power:17 dBm Sensitivity=1/1
          Retry:off RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality=0/70 Signal level=-96 dBm Noise level=-96 dBm
          Rx invalid nwid:22690 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

Looks good to me. Or?

But the dhclient brings no clear result to me:

thosch@betaThoscheee:~$ sudo dhclient
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

wifi0: unknown hardware address type 801
wifi0: unknown hardware address type 801
Listening on LPF/ath0/00:15:af:b5:9f:f0
Sending on LPF/ath0/00:15:af:b5:9f:f0
Listening on LPF/wifi0/
Sending on LPF/wifi0/
Listening on LPF/eth0/00:22:15:12:b1:b7
Sending on LPF/eth0/00:22:15:12:b1:b7
Sending on Socket/fallback
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on wifi0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on wifi0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on wifi0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 19
DHCPDISCOVER on wifi0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 21
DHCPDISCOVER on wifi0 to 255.255.255.255 port 67 interval 19
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 20
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on wifi0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

I cannot interpret this.

@Mackenzie Morgan

Are you shure that this is a problem within madwifi?

Under Ubuntu 8.04 the driver compiled from the same source is running without any problems.

I have a similar issue upon resume with madwifi-hal-0.10.5.6 complied with Ubuntu Intrepid. (The ath5k just isn't up to snuff yet).

With ath5k, though the connection was intermittent and slow, it would resume a connection (that frequently didn't allow much/any traffic). Using NM 0.7 It will try to resume with madwifi, but will go back to a gray globe after a half minute or so.

Running madwifi, if I resume and run

$ ifconfig

I get

ath0
eth0
lo

but no wifi0

issuing
$ sudo ifconfig wifi0 up
then
$ ifconfig
ath0
eth0
lo
wifi0

Then I can go back to NM and connect to my access point.

Resuming from suspend with madwifi doesn't seem to create the virtual wifi0.

A temporary fix [for me] would be for a script to run with resume that would issue "ifconfig wifi0 up" but /etc/acpi/resume.d/ seems deprecated since Hardy, and no scripts I put there run. {ie: 63-wifi-res.sh} Yes, they have been made to be executable and will run for me if I issue from a terminal "sudo /etc/acpi/resume.d/63-wifi-res.sh"

It had under Ubuntu Hardy, but I was using WICD. The latest WICD seems to be broken and made itself difficult to uninstall and so so I went with NM 0.7 which is available in Intrepid as part of the Ubuntu packaging. Under WICD 1.4.2, I had the same issue with madwifi in Intrepid so I don't think it is NM.

Subsribe

FIX/workaround: If you have trouble with reconnection and when you do ifconfig you have my issue of wifi0 being present from boot but not resuming from suspend/hibernate,

open

/usr/lib/pm-utils/sleep.d/10NetworkManager

thaw|resume)
ifconfig wifi0 up <--
resume_nm

add that line assuming this is the virtual device (for you as it is for me) that madwifi creates along with ath0.

You don't need to add ath0 if that seems to show up after resume.

NM reconnects Wifi every time - so far for me anyway.

Brian's FIX worked for me. My wifi wouldn't connect after suspend/resume. Running freshly installed Ubuntu 8.10 RC on a thinkpad t42p with the Atheros 5212 wireless chip.

Three things that I did were

1. added MODULES="ath_hal" to /etc/defaults/acpi-support (not sure if this is significant)
2. added STOP_SERVICES="networking" to /etc/defaults/acpi-support

3. added "ifconfig wifi0 up" to /usr/lib/pm-utils/sleep.d/10NetworkManager (see code block below)

case "$1" in
        hibernate|suspend)
                suspend_nm
                ;;
        thaw|resume)
                ifconfig wifi0 up <-----
                resume_nm
                ;;
        *) exit $NA
                ;;
esac

hope this helps

The fact that it happened on a fresh install on a totally different computer with perhaps a different card pretty much confirms a bug of some sort.

It perhaps isn't madwifi in general, but in some essence an inability for some function in the OS/Kernel to restart the wifi card out of suspend/hibernate in a way that it does when it boot.

I can confirm that this issue happens with resuming from suspend AND hibernate... and in the latter, it is pretty much assured that power is cut completely to the wifi card.

I don't feel like fiddling now because I got it working and that is the most important thing for now, but perhaps something that happens elsewhere during networking start/stop that in previous versions of Ubuntu would pull down/remove configuration for the entire interface and put it back up "fresh." It might speed things up for something that does not need two interfaces coming up (why does madwifi need a virtual device and separate front end anyway?)

I think this because without the fix, this command will NOT bring up wifi0 with ath0 after suspend

sudo /etc/init.d/networking force-reload

nor will a combo of
sudo /etc/init.d/networking stop
sudo /etc/init.d/networking start

So I don't even think it has anything to do with NetworkManager. WICD 1.4.2 also would attempt to reconnect to my essid, then just refuse as well.

Mine card is a tp-link of some Atheros sort, but I don't recall - yanked the Broadcom out of my Acer Aspire LCi two years ago in favor of an Atheros card. Up to recently, it worked like a charm. Works well now, but it was about as much fiddling that I used to do with ndiswrapper with Ubuntu 6.10

Brian's Fix also works for me.

Brian's fix also worked for my Atheros on a Lenovo T60p.

I first added the line with wifi0, but that didn't help. So I added an extra line with ath0, and now it works upon resume :)
Now the only problem is that NM keeps asking for my password, but that is another bug.

Thanks for the fix!

@ Crackh34d

Is the passwordfiled filled or is it empty?

It is filled, but I have to press OK everytime I resume from suspend etc.

It is a nuissance, nothing more :)

But let's discuss this in #271097, this thread is for another bug

Neither of the fixes suggested by Isaac, Brian or Crack34d worked on my Thinkpad T61 running up-to-date Intrepid. Instead, my solution was to follow the instructions outlined in Bug #275692 to add a file

  /etc/pm/config.d/madwifi

containing the line

  SUSPEND_MODULES="ath_pci"

I seem to be having the same issue. If I type "sudo iwconfig ath0 up" after resuming my wireless starts working again.

@Ambiguity

Are you shure, that you use iwconfig? I seems to me that iwconfig doesn't know the parameter "up":
thosch@betaThoSchEee:~$ sudo iwconfig ath0 up
iwconfig: unknown command "up"

ifconfig works for me. And I reconfigure the wifi0-interface. Reconfiguring ath0 seems not to work.

I can confirm this bug.

"sudo ifconfig wifi0 up" works for me.

Same problem for me on an LG T1 with an AR242x 802.11abg network card.

Brian's fix works, with the minor regression that I get a notification stating that the network has been disconnected right after I resume (or maybe that's just how it's supposed to work).

Thanks for the kudos and all:-) It took me a while to figure out and being still somewhat of a novice at Linux, I am glad that something I came up with at least temporarily fixes this for many people.

I am not quite sure why some devices just work with one interface, and other ones need a "virtual" one with it. One usb wifi device I have shows up simply as wlan0. My other desktop has a ralink wifi and it shows up as ra0.

But atheros... ath0 AND wifi0... I am sure there is a reason...

New to the forums and fairly new to linux. After adding "ifconfig wifi0 up" and "ath0 up" I was still having issues. Once I added "ath0 up" only then could I actually see my wireless network as an option to connect to. (I couldn't see any wireless networks to connect to with "wifi0 up") I only had success after adding the line "ifconfig gksudo dhclient" It just made sense to me so I tried it out and it worked. Feel free to comment on that.

Fully patched intrepid amd64 with Atheros 5212 and this bug affects me. Brian's fix above(ifconfig wifi0 up in the script) works great for me.

The fix added by Andreas Jonsson worked for me on my Eee PC 4G running Ubuntu 8.10 and madwifi driver:
https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/272300/comments/23

The Isaac Su-method worked for me: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/272300/comments/17 on Ubuntu 9.04 beta Netbook Remix (Packard Bell dot.3g)