Nixpkgs: supplicant service fails to start on resume from suspend

[shlevy]

On 16.09, I'm using the newer wpa supplicant module for my wireless card:

  networking.supplicant.wlp3s0 = {
    userControlled.enable = true;
    configFile.path = "/etc-persistent/wpa_supplicant.conf";
    configFile.writable = true;
  };

On resume from suspend, I always need to manually start supplicant-wlp3s0.service.

@ts468

[shlevy]

It looks like upon resume it gets a disconnect/deinit of the interface and stops, then doesn't start back up when the interface is back up.

Sep 27 21:48:36 shlevy-laptop wpa_supplicant[813]: wlp3s0: WPA: Group rekeying completed with 6
Sep 28 03:02:02 shlevy-laptop wpa_supplicant[813]: wlp3s0: CTRL-EVENT-DISCONNECTED bssid=60:33:
Sep 28 03:02:02 shlevy-laptop wpa_supplicant[813]: nl80211: deinit ifname=p2p-dev-wlp3s0 disabl
Sep 28 03:02:02 shlevy-laptop systemd[1]: Stopping Supplicant wlp3s0...
Sep 28 03:02:02 shlevy-laptop wpa_supplicant[813]: p2p-dev-wlp3s0: CTRL-EVENT-TERMINATING
Sep 28 03:02:02 shlevy-laptop wpa_supplicant[813]: nl80211: deinit ifname=wlp3s0 disabled_11b_r
Sep 28 03:02:02 shlevy-laptop systemd[1]: Stopped Supplicant wlp3s0.

[shlevy]

(And yes, I did wake up at 3 AM today :tongue: )

[shlevy]

@edolstra Any idea the appropriate way with bindsTo to have the service come back if the bound-to device comes back?

[ts468]

Any chance that one of the two configuration options makes a difference:
extraConf="p2p_disabled=1"
driver="wext"

Just a guess.

[shlevy]

Hmm, not sure why that would matter? It's systemd not restarting the service, not a supplicant issue. Note that if I restart it myself all works well.

[groxxda]

@shlevy just a guess, but partOf = [ "sys-subsystem-net-devices-%i.device" ]; should take care of restarting the supplicant..

By the way: I thought wpa_supplicant by @globin is the _new_ module.. I really don't understand why we have both...
The wpa_supplicant module uses a udev rule and a resumeCommand to restart..

Anyhow: Both look broken to me since they have wantedBy = [ "network.target" ] when they really should have wants = [ "network.target" ] and _maybe_ wantedBy = [ "multi-user.target" ];.

[shlevy]

partOf will restart it if the device restarts, but not if the device goes away and then comes back, right? Maybe we want wantedBy for the device?

supplicant.nix has a shorter history and looks newer to me... Why do we even have two at all? @domenkozar should we remove one?

[ts468]

I wrote supplicant.nix module because I need a per-device supplicant. You still find the line "FIXME: start a separate wpa_supplicant instance per interface." in the wpa_supplicant.nix module. I didn't touch the wpa_supplicant.nix module because I didn't want to force everyone to update their configuration.nix as the change was not backwards compatible.

As if one module should be removed, I think a per-device supplicant is a desirable feature. But it seems that supplicant.nix isn't used by too many people until now so that it might need some more testing and bug-fixing first before we deprecate the wpa_supplicant.nix module?

[globin]

I think they should be merged but I don't want to lose the ability to specify my networks declaritively, supplicant lacks that at least.

[ts468]

@shlevy Unfortunately, I can't test #19093 at the moment myself on a real system, do you maybe have a possibility of doing so?

@globin Let's merge the modules then once this issue is fixed?

[shlevy]

I'm on a terrible network right now and apparently it's too much to ask to pull and push from github, but this patch fixed it for me http://sprunge.us/acbF @ts468 is that change OK?

[ts468]

Sure, just apply your patch, thanks for asking.

Systemd never stops amazing me, here I don't understand why a "wantedBy xyz.device" in the supplicant.service works, but a "wants supplicant.service" in the xyz.device (as specified in the udev rule) does not. I might be missing somethings, but I'm glad you found a way to fix the issue. Thanks!

[shlevy]

Yeah I didn't see that udev rule before, it _should_ be doing the same thing as my patch... Oh well. Will push.

[Profpatsch]

The restart after suspend doesn’t work here, even with that patch.
There are no log outputs in journalctl.

[iblech]

For what it's worth, I can confirm @Profpatsch's observation here (without the patch). journalctl shows that dhcpcd is informed (a kill -HUP is happening), but supplicant is not restarted.

[Profpatsch]

Sudden @iblech