Re: [RFC PATCH 0/8] Export IWD known networks as Connections

[Denis Kenzior <denkenz gmail com>]

Hi Thomas,

> First of all, I think that the NetworkManager profile (in NM's D-Bus
> API) must abstract the Wi-Fi backend. Otherwise, all clients would need
> to learn how to handle iwd-typed profiles. So, this hard work of
> abstracting iwd and supplicant must be done by NetworkManager.

So just let me quickly introduce myself: My name is Denis & I'm the iwd 
maintainer ;)  I've tasked Andrew with getting iwd support in NM 
functional.  Architecturally iwd is quite a bit different from wpa_s, so 
I don't expect things to be easy, but we're fully committed to do this.

In fact, since you have a much better understanding of NM, we would love 
to have you drive some of these tasks to make the process more 
efficient.  Feel free to just tell us what to do / how to do it.

> Maybe a iwd settings plugin is not the right approach, because:
>
> - it would mean, a profile can only be handled by the iwd backend,
> if it is also stored in iwd settings plugin (otherwise, if the iwd
> device plugin can handle profiles in keyfile format, why would we need
> the iwd settings plugin in the first place?).
>
> - it would mean, an existing profile in keyfile format cannot be
> activated with iwd backend. You can no longer deploy profiles in
> keyfile format and have them handled by iwd.

So iwd is pretty similar to BlueZ in this regard.  iwd itself maintains 
all profiles with the big caveat that the WiFi profiles are quite a bit 
more complicated than PAN.  I think this was one of the main motivations 
behind Andrew's proposal.

> - it would mean, when switching the backend, you have to migrate the
> profiles. If such a migration needs to be done manually, it's bad user
> expirience. If such a migration can be done automatically by NM's iwd
> plugin, then we don't need an settings plugin, because this kind of
> "migration" should be the regular modus operandi of the device plugin
> and always do it transparently.
>
>
>
> Note that the device plugin can create profiles automatically. See for
> example
>    
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/bluetooth/nm-bluez-device.c?id=3b1b6427d14473433dadd9b673dcfaab6dc19e25#n182

Good to know.  However, I wonder if such an approach is going to be 
enough?  See more below

> The iwd device plugin could compare the list of available profiles with
> the known networks in iwd daemon. If
>    - a profile only exists in iwd, create an in-memory profile in NM
> representing it.

So this part seems quite straightforward.  The only thing to keep in 
mind is that iwd does not expose any actual profile details in any way. 
So there's no way to know the PSK, EAP details, etc.  We only expose 
high-level details like network type, ssid, autoconnect status, etc.

So I guess the question is, can NM be made to accept such minimal 
profiles or is there another solution that is needed here?

>    - the same profile exists in iwd and NM, update iwd's profile with
> the settings from NM

So this part is tricky for the reasons stated above.  We simply don't 
have any way to obtain this information short of having NM reach into 
iwd's private config directory...

>    - if the profile only exists in NM, create it in iwd.

Assuming we solve the above, this doesn't sound bad.  Except that like 
BlueZ, iwd has no concept of user-only profiles.  I understand (correct 
me if I'm wrong) that NM is multi-user aware and hides user-specific 
profiles from other users..

iwd profiles are intended to be permanent.  So a solution where NM puts 
in profiles and later has to take these out would be less than optimal.

Don't take any of the above as criticisms.  More like these are the 
issues, how do we solve them?

Regards,
-Denis