wpa_supplicant's control socket disappears after suspend (regression?)

[Andrew Shadura]

On 19/11/16 12:22, Jouni Malinen wrote:
> On Wed, Nov 16, 2016 at 09:55:41PM +0100, Andrew Shadura wrote:
>> Shortly after wpa_supplicant 2.6 was released, I uploaded it to Debian
>> experimental and started using it on my work machine (which runs
>> Ubuntu). I soon noticed I often have no wireless connection upon resume
>> from suspend, much more often than what I had with either 2.4 or 2.5.
>> Also, previously wpa_cli scan would reconnect to the network, now it
>> fails to talk to wpa_supplicant:
>>
>> Could not connect to wpa_supplicant: (nil) - re-trying
> 
> It looks like something in the system is killing wpa_supplicant during
> suspend/resume. Or at least your log showed wpa_supplicant started after
> resume. Do you know why the process gets killed for that? That would
> remove the control interface.. And the way it is started here with NM
> would not bring back the per-interface control interface before NM has
> (re-)added the interface into the new wpa_supplicant process.

I don't know yet. I however realised now that it was probably behaving
the same way with 2.5, but what changed was the interaction between NM
and wpa-supplicant. Why I am thinking that:

In some past version of Ubuntu wpa-supplicant package, a maintainer
introduced an on-resume script which would do `wpa_cli resume`, and when
I tried to port that to Debian I noticed it fails to find the
wpa-supplicant socket, even though a couple of seconds later it finds it
just fine.

That makes me think NM talked to wpa-supplicant at resume and tells it
to manage the interface — but it doesn't do (or fails to do) so now (in
the past, the wifi networks list in nm-applet would be empty, now it
says "device not managed").

>> Restarting both wpa_supplicant and network manager often helps, but
>> drives nm-applet crazy for some reason, and I have to restart it. Until
>> I restart NM, the interface shows as unmanaged in the applet's menu.
> 
> "often helps"? Are you implying this does not always get the
> wpa_supplicant control interface back?

Hmm, in fact it helps every time. It's just in the past I didn't have to
restart it, wpa_cli scan would make it find the network and connect to it.

>> I attempted to run wpa_supplicant manually using the command line from
>> its .service file and use wpa_cli, and found out it stopped creating the
>> control socket.
> 
> Stopped creating? Are you saying that an earlier version behaves
> differently when started manually? If you do not specify any interface
> on the command line, there cannot really be a per-interface control
> interface before that interface has been dynamically added based on the
> NM request later..

Does it maybe make sense to run wpa-supplicant in a way it always has
the socket available as we're not really using per-device sockets (and
therefore there can be only one /run/wpa_supplicant socket at any time).

-- 
Cheers,
  Andrew