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

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

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

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

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