Nixpkgs: Why are there two wpa_supplicant option sets?

[Profpatsch]

There’s networking.wireless maintained by globin.
Then there’s networking.supplicant, maintained by nobody and changed by @ts468 @groxxda.

What is the reason for that duplication?

[edolstra]

Huh, never noticed. It appears the supplicant module was introduced in c6b2365e9a3f95e2665f8c518781bc007aa055f8, with no motivation as to why we need another module for the same service. I would say get rid of it.

[Profpatsch]

I tried both, both are kind of buggy, but the supplicant module is more advanced it feels.

e.g. supplicant doesn’t restart wpa_supplicant after suspend, but it does handle the configure file better.

[ts468]

Supplicant isn't for wireless only. It can e.g. also be used to authenticate with 802.1x capable switches.

There has been some discussion about that issue already, and ideally they should be merged, see https://github.com/NixOS/nixpkgs/issues/19029#issuecomment-250248088.

[globin]

I'll try and merge them next week.

[ts468]

@globin Let me know if I can help. I already had a brief look at it [1], but I'm not so sure how to handle the reported issue that wpa_supplicant does not restart on resume. On the one hand I'd like to keep the per-device activation, and therefore I think udev is the right tool, on the other hand your solution from wpa_supplicant.nix seems to work more reliably at the moment. As I said, let me know, I'm very happy to help.

[1] https://github.com/ts468/nixpkgs/tree/supplicant

[Profpatsch]

The interesting part will probably be what the new api should be and how to handle deprecation.

[ts468]

I'm wondering if systemd 233 [1] has an effect on the resume after suspend issue we're seeing with supplicant:

• When units are about to be started an additional check is now done to
  ensure that all dependencies of type BindsTo= (when used in
  combination with After=) have been started.

[1] https://github.com/systemd/systemd/blob/master/NEWS

[ts468]

@globin As I'm responsible for the duplication of wpa_supplicant, please let me know how I can help resolving that blocker.

[globin]

Yeah, I'm not really sure how to merge these modules properly.. I don't like breaking backward compatibility in networking.wireless so that merging the modules isn't easy. I'd personally prefer removing supplicant in 17.03 and having the missing options from supplicant merged into networking.wireless for 17.09.

@ts468 what do you think?

[ts468]

So how the udev rules in supplicant _should_ work is by firing on the first match:

• match the device on the device name
  -> start a supplicant with the associated configuration for that device
• match the device on the device type WLAN/LAN
  -> start a supplicant with the general configuration of WLAN/LAN devices (again, one supplicant is started for each WLAN/LAN device)

What if we put the configuration option for the per-device supplicant under networking.interfaces.<name?>.supplicant, and the configuration option for the group of WLAN devices under networking.wireless?

That way we could keep the per-device configuration option, could have a clear deprecation strategy for the current networking.supplicant.<name?> configuration options from supplicant, and keep the networking.wireless configuration option for setting the default configuration for all wireless interfaces?

The reason I'm hesitating a bit is because there seems to be an unresolved issue with supplicants that are configured in supplicant not restarting properly after a suspend-resume cycle. So if we want to settle for the udev-based approach, then we would have to debug that problem properly!

@globin What do you think?

[Profpatsch]

there seems to be an unresolved issue with supplicants that are configured in supplicant not restarting properly after a suspend-resume cycle

Can confirm.
Have to execute sudo systemctl restart supplicant-wlp3s0.service after every wakeup from standby.

[ts468]

@Profpatsch, in that case, could you maybe help me debugging it, please?

What _should_ happen is that:

1. on suspend, the <device> should be removed (by some logic); however, udev should not remove the supplicant-<device>.service directly, there is no udev rule for REMOVE.
2. instead, the supplicant-<device>.service BindsTo the ...-<device>.device, and so the supplicant-<device>.service should be killed by systemd.
3. on resume, udev should ask systemd to bring up the supplicant-<device>.service as it adds a Wants from the ...-<device>.device to the supplicant-<device>.service; that is what the udev ADD rule is for.

Now, obviously something goes wrong somewhere. Could you maybe help me figuring out what it could be?

My first guess would be that somehow 2. and 3. are not executed in strict order. Could you maybe play around with adding something like a udev REMOVE rule with RUN=systemctl stop supplicant-<device>.service? Or, powerManagement.resumeCommands = systemctl try-restart supplicant-<device>.service? At least that's what seems to work in the wpa_supplicant.nix module. Or or course anything else that you might think of! ;)

Your help would be highly appreciated!

[ts468]

@globin Should we try to tackle this one? Could you maybe comment on my suggestion from above? It will be a rush implementing it anyways, but just to have a few more days ;)

@Profpatsch Could we have your help as well, please? Or, has the issue been resolved for you already? Many thanks! :)

[Profpatsch]

Could we have your help as well, please? Or, has the issue been resolved for you already? Many thanks! :)

I’ve kind of been hoping that you’d implement the merge and everything just works magically from that point. :)
A bit out of my league with udev and haven’t had the time to read into that. It seems to work for most people, right? So I’d suggest doing the merge first.

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.