Add a new [device*] section to NetworkManager.conf. This works similar
like the default connection settings in [connection*].
This will allow us to express per-device configuration in NetworkManager.conf
in our familar style.
Later, via NMConfig's write API it will be possible to make settings
accessible via D-Bus and persist them in NetworkManager-intern.conf.
This way, the user can both edit configuration snippets and modify
them via D-Bus, and also support installing default configuration
from the package.
In a way, a [device*] setting is similar to networkd's link files.
The match options is all encoded in the match-device specs.
One difference is, that the resulting setting can be merged together
by multiple section by partially overwriting them. This makes it
more flexible and allows for example to drop a configuration snippet
that only sets one property, while the rest can be merged from different
snippets.
Avoids the following error when ofono isn't running:
NetworkManager[25133]: <info> [1466186144.1392] ofono is now available
NetworkManager[25133]: <warn> [1466186144.1637] failed to enumerate oFono devices: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
because the code assumes that if the GDBusProxy is created, that
oFono is available. That's not the case with DO_NOT_AUTO_START
because it creates the proxy anyway, and lets the caller listen
for name-owner-changed signals instead. The GDBusProxy also
doesn't need to be cleared, since it will follow name-owner
changes and emit g-name-owner changes when oFono starts/stops.
This also fixes the oFono name-owner-changed watch. It was presumably
using the signal name copied from the ModemManager 'notify::name-owner'
code, but that's a GDBusObjectManagerClient. The oFono code is using
a GDBusProxy for which the signal is 'notify::g-name-owner'.
Finally, the oFono code shouldn't really be piggy-backing on the
ModemManager autolaunch code, it's just cleaner to keep the two
code paths separate and initialize oFono in parallel.
NM_MODEM_UID is used as the modem device name, and the device name
cannot contain path-like characters.
Ofono has a bluez plugin that detects paired DUN/PAN capable
Bluetooth devices, and these devices are created with a multi-component
object path like "/hfp/org/bluez/hci0/dev_00_26_E2_AB_68_66".
The NM ofono plugin cannot use these paths as NM device names.
Instead, strip off any path components and use the last part
of the object path as the NM device name.
At least, there are assertions that fail and must be fixed.
Still, let's merge the (incomplete) ofono patches early
to have something that can be incrementally improved.
However, for now mark it as experimental and disable it by
default.
