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

On Tue, 2018-06-12 at 10:21 +0200, Andrew Zaborowski wrote:
From: Andrew Zaborowski <balrogg gmail com>

Connecting to 802.1x wifi networks preprovisioned as IWD config files
doesn't work very well currently as you have to have an NM Connection
with the same SSID and security type set to WPA-Enteprise for the
to command IWD to connect.  For that you need to create a connection
fill in all the EAP details just so NM accepts the connection

This is a propsal to add an IWD-specific settings plugin that
IWD's KnownNetworks as existing Connections to dbus clients so that
information is not duplicated between IWD and NM config files
since IWD won't save many of the settings that are important to NM it
may still be a good idea to have NM config files for those
but without duplication), and later allow deleting configured

The patches just implement a minimal plugin with a few open
If NMIwdManager was to create and remove the connection objects
registering as a plugin it couldn't override the connection
and they'd still be performed by the keyfile plugin.  But I'm not
where it's best to place the plugin within the source or whether it
should be built as a separate binary.  Also whether the connections
created should be somehow locked to only IWD devices when NM is
configured to use both the IWD backend and the wpa_supplicand backend
for different devices -- connection.interface-name and
802-3-ethernet.mac-address would only allow one interface to be
specified.  Having devices using both backends is a really strange
configuration and I don't see much value in supporting it.

Hi Andres,

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

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

- 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

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

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.


Andrew Zaborowski (8):
  wifi: Move get_connection_iwd_security to nm-wifi-utils.c
  wifi: Move KnownNetworkData to nm-iwd-manger.h
  iwd: Emit known-networks-changed signals from NMIwdManager
  iwd: Add nm_iwd_manager_forget_network API
  settings: Allow loading plugins after startup
  libnm-core: 8021x: Allow a new eap value "extern"
  settings: Add an IWD plugin
  iwd: Register the IWD settings plugin                                   |   6 +-
 libnm-core/nm-setting-8021x.c                 |   3 +-
 src/devices/wifi/nm-device-iwd.c              |  35 +----
 src/devices/wifi/nm-iwd-manager.c             |  88 +++++++++++--
 src/devices/wifi/nm-iwd-manager.h             |  10 ++
 src/devices/wifi/nm-wifi-utils.c              |  23 ++++
 src/devices/wifi/nm-wifi-utils.h              |   3 +
 src/settings/nm-settings.c                    |  66 ++++++----
 src/settings/nm-settings.h                    |   4 +
 src/settings/plugins/iwd/nms-iwd-connection.c | 173
 src/settings/plugins/iwd/nms-iwd-connection.h |  43 +++++++
 src/settings/plugins/iwd/nms-iwd-plugin.c     | 176
 src/settings/plugins/iwd/nms-iwd-plugin.h     |  37 ++++++
 13 files changed, 604 insertions(+), 63 deletions(-)
 create mode 100644 src/settings/plugins/iwd/nms-iwd-connection.c
 create mode 100644 src/settings/plugins/iwd/nms-iwd-connection.h
 create mode 100644 src/settings/plugins/iwd/nms-iwd-plugin.c
 create mode 100644 src/settings/plugins/iwd/nms-iwd-plugin.h

Attachment: signature.asc
Description: This is a digitally signed message part

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