On Tue, 2018-06-12 at 10:21 +0200, Andrew Zaborowski wrote: > From: Andrew Zaborowski <[email protected]> > > 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 >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
