Should this target staging, maybe?

Should this target staging, maybe?

Don't think so. It shouldn't cause a mass rebuild since the feature is already enabled, changes don't touch the networkmanager expression.

So i tried using this and it appears there is some config that should be shared between the iwd module.
This probably worked for because maybe you were using it before.

diff --git a/nixos/modules/services/networking/networkmanager.nix b/nixos/modules/services/networking/networkmanager.nix
index 0dc4aec95ab..1d4c1dd585e 100644
--- a/nixos/modules/services/networking/networkmanager.nix
+++ b/nixos/modules/services/networking/networkmanager.nix
@@ -526,5 +526,11 @@ in {
       optional cfg.enableStrongSwan pkgs.strongswanNM ++ cfg.packages;
 
     services.udev.packages = cfg.packages;
+
+    systemd.services.iwd.wantedBy = mkIf (cfg.wifi.backend == "iwd") [ "multi-user.target" ];
+
+    systemd.tmpfiles.rules = mkIf (cfg.wifi.backend == "iwd") [
+      "d /var/lib/iwd 0700 root root -"
+    ];
   };
 }

with that it worked on my system.

I have to ask if they're really mutually exclusive? How does NetworkManager use iwd?
Edit: looked and for nixos we need the same configuration as what's in the iwd module. Not sure there's a clearer way to not duplicate it, but I think it's fine for this change.

You should also include #68213 for networkmanager.

Hm, I thought the assert that's in this change was specifically because NM controls the IWD lifecycle when IWD is used with NM. I may have had the /var/lib/iwd directory because I had briefly directly enabled iwd, but my setup is working fine without the extra wantedBy you have suggested, again (I thought), due to NM controlling the IWD lifecycle in this scenario.

Do you want me to pull the commit from #68213 in here, or just review it and make this PR depend on merging it first?

Hm, I thought the assert that's in this change was specifically because NM controls the IWD lifecycle when IWD is used with NM. I may have had the /var/lib/iwd directory because I had briefly directly enabled iwd, but my setup is working fine without the extra wantedBy you have suggested, again (I thought), due to NM controlling the IWD lifecycle in this scenario.

Yeah, I think because of that the state directories would already have been ready.
The wantedBy is already in the iwd module so that's why it's there.

Do you want me to pull the commit from #68213 in here, or just review it and make this PR depend on merging it first?

I'm not sure if we're going the route of enabling the iwd module conditionally within the networkmanager module (I think it could be possible) or duplicating it.
Looking at the code here, using cfg.packages actually adds the packages to the same options as the iwd module does already. So I think it would be fine to just enable iwd within the networkmanager module.

We discussed in depth on irc

• https://logs.nix.samueldr.com/nixos/2019-09-06#2563827;

@worldofpeace It seems like chain-enabling the iwd nixos option worked.

Can you take a look? I think I've addressed everything you mentioned now?

@colemickens, new change got merged that added another variable to check into the mix.
I added b07d6f5 for this, I hope you don't mind.

I had to do some weird merging fixups when I cherrypicked the ell/iwd-bump and then these two commits, but it seems to work fine. Should I squash and repush these, @worldofpeace ?

I had to do some weird merging fixups when I cherrypicked the ell/iwd-bump and then these two commits, but it seems to work fine. Should I squash and repush these, @worldofpeace ?

Sure, I'll also request the review of one more person 👍

It would have been no-op until b4044a3 landed. We could revert it on master to fix the issue, as the assertion for that was broken. And then we can revert my fixup commit and merge.
Though I'm short on time with other things currently.

I'll check it out until tomorrow how to reconcile this with b4044a3.

I'm not sure why

networking.networkmanager.enable = true;  
networking.wireless.enable = true;

works for you, @worldofpeace. 🤔
The assertion clearly rules that out. Do you have networking.networkmanager.unmanaged set to a non-empty list somewhere?

With the new changes here, though, I'd add this diff to the PR:

--- i/nixos/modules/services/networking/networkmanager.nix
+++ w/nixos/modules/services/networking/networkmanager.nix
@@ -394,10 +394,12 @@ in {
   config = mkIf cfg.enable {

     assertions = [
-      { assertion = config.networking.wireless.enable == true -> cfg.unmanaged != [];
+      { assertion = config.networking.wireless.enable ->
+          (cfg.unmanaged != [] || cfg.wifi.backend == null);
         message = ''
           You can not use networking.networkmanager with networking.wireless.
-          Except if you mark some interfaces as <literal>unmanaged</literal> by NetworkManager.
+          Except if you mark some interfaces as `unmanaged` by NetworkManager
+          or set the wifi backend to `null`.
         '';
       }
       { assertion = !dynamicHostsEnabled || (dynamicHostsEnabled && cfg.dns == "dnsmasq");

Huh, I tested again on a running system and I get the assertion message. I guess you can't test this with a vm.

Also, I'm not sure if networkmanager has a concept of not using any backend. So allowing null as a value doesn't make sense. What actually matters is what's set as unmanaged.

@JohnAZoidberg I believe this should be correct now.

This works for me. But dhclient gives me the following error:

Can't bind to dhcp address: Address already in use
Please make sure there is no other dhcp server
running and that there's no entry for dhcp or
bootp in /etc/inetd.conf.   Also make sure you
are not running HP JetAdmin software, which
includes a bootp server.

If you think you have received this message due to a bug rather
than a configuration issue please read the section on submitting
bugs on either our web page at www.isc.org or in the README file
before submitting a bug.  These pages explain the proper
process and the information we find helpful for debugging.

exiting.

So I guess dhclient shouldn't be running when using iwd?

Interesting,

This works for me. But dhclient gives me the following error:

Can't bind to dhcp address: Address already in use
Please make sure there is no other dhcp server
running and that there's no entry for dhcp or
bootp in /etc/inetd.conf.   Also make sure you
are not running HP JetAdmin software, which
includes a bootp server.

If you think you have received this message due to a bug rather
than a configuration issue please read the section on submitting
bugs on either our web page at www.isc.org or in the README file
before submitting a bug.  These pages explain the proper
process and the information we find helpful for debugging.

exiting.

So I guess dhclient shouldn't be running when using iwd?

We currently default to internal. Also, I'm not sure if the problem would be them conflicting in any way. iwd has nothing to do with dhcp.

We currently default to internal. Also, I'm not sure if the problem would be them conflicting in any way. iwd has nothing to do with dhcp.

Actually, I think dhclient is the default if I read the code on master correctly.
Also from the Arch Wiki:
Since version 0.19, iwd can assign IP address(es) and set up routes using a built-in DHCP client or with static configuration.
Although according to https://git.kernel.org/pub/scm/network/wireless/iwd.git/commit/?id=199e647ffde38584d5bab609de38bea973082ffe iwd's internal dhcp should be off by default.

@xaverdh Oh, that change hasn't hit master yet 1ff3a0c.

And it does seem it has this function. I don't think the module for iwd handles any config file so I bet our issue is right there.

Indeed with internal dhcp everything works just fine.

For your information, this pull request fixes #69368 (thanks @xaverdh). (Or not sure if fixing the issue is correctly said, but at least offers one workaround.)

OT: what's the advantage of using iwd as a NM backend as opposed to just using iwctl?

Not familiar with these, so I might speak nonsense, but AFAIU, NetworkManager has everything in one place. So you can manage wired&wireless connections and VPN from one app/applet/trayicon.

Rebased as I've removed the basePackages #70041 code which was unneeded.