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

[Andrew Zaborowski <andrew zaborowski intel com>]

On 21 June 2018 at 15:17, Thomas Haller via networkmanager-list
<networkmanager-list gnome org> wrote:
> 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.
>
>
>
> 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?).

Yes, that's not optimal but that's also the current situation with
profiles that only the wpa_supplicant can handle.

> - 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.

This is also true now for 802.1x wifi profiles.

> - 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.

So switching backends is not an operation that the majority of users
should ever need and, while it'd be nice if it worked, there are a
number of rare features that will simply not work with the IWD backend
because IWD does not support them.  There are also things that don't
currently work, like connecting (easily) to 802.1x networks, but which
could be made to work although without the added benefit that the
networks will keep working after switching backends.

> 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

Yes, I considered this, I have put the code that creates networks
under src/settings/plugins/ as a proposal, to start this discussion
and see what ideas you, the NM developers, may have... but it could
equally well live in src/devices/wifi/.  You'll notice that the
NMSIwdConnection class doesn't do much except in the constructor.

One thing that a plugin allows us to do though is react to the network
being deleted (forgotten) or modified (not supported in the patchset).
This could also be done through a new mechanism that is not a settings
plugin.

> 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.

Since IWD keeps the EAP authentication settings internal this would
still need to be an "incomplete" (from wpa_supplicant's point of view)
profile, although that would work for us.

>   - the same profile exists in iwd and NM, update iwd's profile with
> the settings from NM
>   - if the profile only exists in NM, create it in iwd.

So updating or adding 802.1x profiles from the Network Manager is not
something that we want to support initially so these two situations
are not our current concern and they'd need NM to understand the IWD
config file syntax similarly to the ifcfg-rh plugin, and write the IWD
config files directly.

> I think, settings plugins have a limited use. Indeed, few settings-
> plugins exists, and most of them are read-only. The only extensive
> plugin is ifcfg-rh, which is a huge management burden. But with ifcfg-
> rh, NM only uses the ifcfg file format to persist a profile. The
> profile is still fully handled by NetworkManager. By using the same
> file format and actual files, the user can run `ifup` (with NM
> disabled) and `nmcli con up` (with NM enabled). In practice, this only
> works well to a certain point, because initscripts and NM support
> different features and behave differntly in many aspects.

Right, and the concept of the plugin I proposed is a little different
as it would need to effectively handle all wifi connections while IWD
is the active backend.

Best regards