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

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

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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]