Re: Doesn't reconnect to wifi after resuming from suspend

poma wrote:

On 06.02.2015 18:42, Ferry Toth wrote:
poma wrote:

On 05.02.2015 22:00, Ferry Toth wrote:
poma wrote:

On 05.02.2015 20:12, Ferry Toth wrote:

Would that be after a certain kernel? But I used 14.04 with kernel
3.17 (no problem) and 14.10 with 3.17 (and now 3.18)

See if it can help

Thanks by I don't find my case there.

Description=Reload Atheros 802.11n wireless LAN cards driver

ExecStart=/usr/sbin/modprobe -r ath9k
ExecStart=/usr/sbin/modprobe ath9k


# systemctl enable ath9k-reload.service

# systemctl suspend
          & RESUME

# systemctl hibernate
          & THAW

# systemctl hybrid-sleep
          & RESUME||THAW

Does it work?

Actually no, it doesn't. I already suspected that as I tried other
similar (non-systemd) scripts that restart stuff on resume.

With this script, it doesn't even autoreconnect on boot (which did work


As you can read, in the mechanism of ath9k-reload.service, it by any means
should not affect the Soft-Off/boot, but only Suspend-to-Disk/thaw and/or

I am starting to believe that after the drivers go up, an event scan is
started, and the ath9k incorrectly reports that it is done (but might not
be, as I have 2.4G and 5G and am trying to reconnect to the 5G).

Just restarting drivers won't fix this (if it is indeed so).

I need a delay after resume and scan, and before the autoconnect starts.

BTW when I do:
lsmod | grep ath

ath9k                 162133  0
ath9k_common           25638  1 ath9k
ath9k_hw              460416  2 ath9k_common,ath9k
ath                    29397  3 ath9k_common,ath9k,ath9k_hw
mac80211              697212  1 ath9k
ath3k                  13381  0
cfg80211              520257  4 ath,ath9k_common,ath9k,mac80211
bluetooth             486890  7 bnep,ath3k,btusb,rfcomm

Rather than speculate, try to contact and consult with folks at

Good luck

Actually I'm not speculating, but hypothesizing. 

I tried manually connecting, but then as fast as possible after resume and I 
get the same problem as with autoconnect.

So apparently, manual connect is working good, when attempted > 5 sec or 
after resume. This leads me to believe that 'something is busy' without 
networkmanager knowing it. A network scan is what comes to mind.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]