wpa_supplicant stops working after pm-suspend
Wed Dec 17 07:25:58 PST 2014
On Tue, 2014-12-16 at 12:24 -0500, Aaron Small wrote:
> I use wpa_supplicant with NetworkManager on linux to connect to wifi. A few
> months ago after a platform update (I'm not sure exactly what was updated,
> whether it included wpa_supplicant and/or other things), wifi stopped
> working after pm-suspend/resume.
Is NetworkManager getting the suspend/resume notification so it can kick
wifi? You should see this:
NetworkManager: <info> wake requested (sleeping: yes enabled:
NetworkManager: <info> waking up...
if you don't, then NM isn't getting suspend/resume notifications and it
may not attempt to reconnect. NM can listen to either systemd, upower,
or pm-utils for this notification. But you have to enable systemd or
upower at build time.
> I found a workaround is to kill and restart wpa_supplicant after resume, so
> I left it with that workaround until now, but am now trying to find what
> actually broke.
> So I am wondering: should wpa_supplicant work after pm-suspend/resume, or
> is it normal that it needs to be restarted? Because I was using it with
> NetworkManager, I don't know, maybe NetworkManager was restarting it
> before, and isn't now and that's what broke.
> I can reproduce the issue without NetworkManager, with wpa_cli (though I
> don't know for sure that this would have worked in the past), and from the
> logs I capture there, it seems like it's at least trying to work, but maybe
> the kernel isn't letting it - I see this in syslog on resume:
> Dec 16 11:40:21 beta kernel: [19624.201689] wlan0: authenticate with
> Dec 16 11:40:21 beta kernel: [19624.217532] wlan0: send auth to
> 00:24:01:6f:15:3f (try 1/3)
> Dec 16 11:40:21 beta kernel: [19624.219438] wlan0: authenticated
> Dec 16 11:40:26 beta kernel: [19629.223804] wlan0: deauthenticating from
> 00:24:01:6f:15:3f by local choice (reason=3)
> and this in wpa_supplicant's log on resume:
> wlan0: SME: Trying to authenticate with 00:24:01:6f:15:3f (SSID='oakmore'
> freq=2437 MHz)
> CTRL_IFACE monitor sent successfully to /tmp/wpa_ctrl_9783-21\x00
> wlan0: State: SCANNING -> AUTHENTICATING
> EAPOL: External notification - EAP success=0
> EAPOL: External notification - EAP fail=0
> EAPOL: External notification - portControl=Auto
> wlan0: Determining shared radio frequencies (max len 1)
> wlan0: Shared frequencies (len=0): completed iteration
> nl80211: Authenticate (ifindex=14)
> * bssid=00:24:01:6f:15:3f
> * freq=2437
> * SSID - hexdump_ascii(len=7):
> 6f 61 6b 6d 6f 72 65 oakmore
> * IEs - hexdump(len=0): [NULL]
> * Auth Type 0
> nl80211: Authentication request send successfully
> wlan0: SME: Authentication timeout
> wpa_driver_nl80211_deauthenticate(addr=00:24:01:6f:15:3f reason_code=3)
> which seems to me like wpa_supplicant is trying to connect and linux is not
> allowing it? But if something is wrong in the kernel, then I'm not sure why
> restarting wpa_supplicant would fix it.
> I'd rather not look into the kernel if I don't have to, but based on these
> logs, would that be the next place to look?
> HostAP mailing list
> HostAP at lists.shmoo.com
More information about the Hostap