This is step 1 towards the ability to, basically, use nm-connection-editor to edit IWD connection profiles. This can be controlled with a new config setting that I'm adding, [main].iwd-config-path, empty by default.
As described in the last commit message the logic where we watch for NMSettingConnection creation and modification signals and mirror those in the IWD's config directory files, has a few shortcomming but I think it's better than nothing. The most obvious problem is that many NMSettingsConnection can refer to the same Wi-Fi network (identified by SSID+security type) but IWD can have only one profile with that SSID+security tuple.
This also is going to be a shift in the policy that we had documented before where if you wanted to connect to WPA-Enterprise networks you were expected to preprovision IWD with the network config files, even if you had them configured in NM already, while now you can add the connection in NM and edit the EAP settings from nm-connection-editor. This code won't convert pre-existing NMSettingsConnections but this may be added in the future. It would perhaps also make sense to convert the NMSettingsConnection at the time that the user requests an activation.
- the connection settings that the
NM_SETTINGS_CONNECTION_UPDATED_INTERNALhandler receives may or may not contain the system-owned secrets. It seems there's no quick way to know whether they're there or not. For example after an activation they're cleared but if there was a D-Bus
GetSecrets()call after that, they will be there again. What we want is to have all of the secrets that are persisted in the NM keyfile. We can request them with the
NM_SECRET_AGENT_GET_SECRETS_FLAG_ONLY_SYSTEMflag but it makes no sense to be requesting them inside the signal handler. The signal handler may be called as a result of the secrets being cleared.
- there are too many
NM_SETTINGS_CONNECTION_UPDATED_INTERNALsignals, in my case most seem to be the result of the system-secrets being moved from the NMConnection to the secrets cache (
priv->system_secrets) and back, with no changes in the actual connection data or secrets. Possibly
NM_SETTINGS_SIGNAL_CONNECTION_UPDATEDis a better option.. although the D-Bus signals are emitted just as frequently as
NM_SECRET_AGENT_GET_SECRETS_FLAG_ONLY_SYSTEM. Maybe this should be changed. In D-Bus traces that signal triggers a bunch of clients to immediately call
GetSettings()which returns the exact same settings as before, i.e. there's no change visible to the client and it only unneeded traffic. Now tracked as #599 (closed).