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 backend to command IWD to connect. For that you need to create a connection and fill in all the EAP details just so NM accepts the connection settings. This is a propsal to add an IWD-specific settings plugin that presents IWD's KnownNetworks as existing Connections to dbus clients so that information is not duplicated between IWD and NM config files (although, 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 connections, but without duplication), and later allow deleting configured networks. The patches just implement a minimal plugin with a few open questions. If NMIwdManager was to create and remove the connection objects without registering as a plugin it couldn't override the connection operations and they'd still be performed by the keyfile plugin. But I'm not sure 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 example https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/bluetooth/nm-bluez-device.c?id=3b1b6427d14473433dadd9b673dcfaab6dc19e25#n182 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. best, Thomas
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 Makefile.am | 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