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

[Ferry Toth <ftoth telfort nl>]

Dan Williams wrote:

> On Tue, 2015-02-03 at 23:15 +0100, Ferry Toth wrote:
> > On my home wifi network I have 1 2.4GHz and 1 5GHz AP (is actually 1
> > fritz box).
> >
> > With one machine (chromebook running kubuntu 14.10 and AR9462 abgn wifi)
> >
> > When automatically reconnecting to 5GHz after resume half of the time the
> > connection fails and retries indefinitely. It seems to fail more when
> > moving the laptop to another location in house while it sleeps (so the
> > list of visible networks actually changes).
> >
> > When this happens it is almost impossible to reconnect manually.
> >
> > (what works sometimes is disconnecting the connection that is building,
> > disable the wifi, enable again, wait a bit then manually connect to the
> > other (2.4GHz) AP)
> >
> > Strangely: disabling autoconnect on resume and then manually connecting
> > always works.
> >
> > Other strange thing: Another machine (NUC with intel wifi and same
> > kubuntu 14.10) always works.
> >
> > To me, it seems to be some interference between rescanning and
> > connecting.
> >
> > I have no idea what is the difference in the state machine when
> > autoconnecting vs. manual.
> >
> > I've provided log's on bugzilla
> > https://bugzilla.gnome.org/show_bug.cgi?id=726121
>
> I updated the bug with some thoughts after looking at the logs.  It
> looks to me like the issues are exclusively driver and/or supplicant
> problems.  In the failed automatic log, the access point and the device
> don't agree on state, so the access point rejects the device.  That
> starts a reconnect attempt which then apparently fails at the driver
> level because the AP never responds to teh driver's association
> attempts.  Later on, the supplicant enters the scanning state but has to
> time that out because the driver never notifies the supplicant that the
> scan has finished.  Even later, the supplicant screws up by trying to
> associate with 00:00:00:00:00:00 and then it simply falls over.
>
> One thing you could do is try to set up a resume-time script that just
> does 'rmmod ath9k; modprobe ath9k' and see if that fixes most of your
> issues; if so then it's usually an indication of driver bugs.  Given
> that iwlwifi works fine on the machine, I think the issues are specific
> to the ath9k driver, and not the mac80211 stack (which iwlwifi also
> uses).
>
> Dan

I did a quick test:
1 - close the lid (suspend)
2 - open the lid (resume)
3 - login as quickly as possible (< 2sec)
4 - manually connect the wifi (<1sec)

The connection then fails the same as with auto reconnect.

So it looks as if the autoreconnect fails because it starts too early after 
resume.

Might it be that it starts connecting too early because it thinks the scan 
is completed although it really is not?