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.
Previously we created a new NMIP[46]Config object to replace the
previous one every time the plugin reported a new IP configuration
through the Ip[46]Config signal, but the old configuration was not
removed from the DNS manager and would become stale.
The interaction with DNS manager is handled by NMPolicy, which only
reacts to changes in connection status, so it's not easy to have the
configuration removed from DNS while keeping the connection state
ACTIVATED.
A cleaner solutions is to avoid creating a new IP configuration object
and reuse the existing one if possible. The side effect is that the
D-Bus path of the object will not change, which seems also positive.
https://bugzilla.redhat.com/show_bug.cgi?id=1348901
If the plugin sends a new configuration when the connection is already
activated the state should not go back to PRE_UP since this causes
dispatcher scripts to run again.
This would fix for example:
nmcli e <TAB>
(e interpreted as --escape, would allow autocompletion to work... but
when the command is executed an error is reported)
Moreover, we will now have:
nmcli c <TAB>
autocompletion work correctly, i.e., c is correctly interpreted as
"connection" instead of "--colors"
Software devices must report the NM_DEVICE_CAP_IS_SOFTWARE capability
in order to be properly activated. Add the flag to NMDeviceTun and
NMDeviceVxlan.
https://bugzilla.gnome.org/show_bug.cgi?id=767846
When NM looks for vpn plugins, it would expect the full service name
otherwise it will not be able to retrieve the correct plugin.
Fixes VPN configurations generated with "nmcli connection add".
It's possible for wpa_supplicant to transition to INACTIVE
state with an outstanding requested_scan pending. This can
lead to a stall condition where scanning no longer occurs.
[thaller@redhat.com: added break statement to avoid fall-through]
https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00116.html
nl_recv() in libnl3 before version 3.2.15 would return dangling pointers
if nl_recv() fails or has nothing to read [1].
Workaround that by explicitly clearing @buf and @creds.
https://bugzilla.gnome.org/show_bug.cgi?id=767986
[1] 69468517d0
Re-enable the check on ambiguos properties but this time manage perfect
matches (i.e., the full property name has been typed) that are prefix
of other properties.
Test case:
nmcli --complete-args connection add type wifi wifi.
Here "wifi" is a property alias that is also prefix of the property
alias "wifi-sec".
When parsing arguments of "connection add" we first read the available
property-value pairs and then check if the --ask option was passed in
order to aid in the fill process of a new connection.
Anyway, if there are no property-value tuples at all, we don't even
check the --ask option, returning with error.
Fix this just checking if any arg is there (argc) before invoking
read_connection_properties().
If we found that setting name prefix is in fact unambiguous and return
the completion string for that setting we were freeing the string upon
the return. That looks like a typo.
Fixes "nmcli --complete-args add type wifi wifi."
^^^^ not ambiguous
It allows us to clean up the nmcli "c add" section considerably.
We list the old-fashioned aliases in a separate section that applies to both
"nmcli c add" and "nmcli c modify".
The section is now nicely cross-linked with nm-settings in HTML
rendering.
This is a huge refactoring in attempt to 1.) reduce the horrible redundancy in
the connection addition path and 2.) reduce confusion between various sources
of property value (command line, properties, interactive mode).
* The conversions from the strings was done all over the place:
settings.c already does for all sensible properties.
The rest is removed.
* The validations are done randomly and redundantly:
server does some validation, and per-property client validations
useful for interactive mode are done in settings.c
The rest is removed.
* The information about defaults and required options was redundantly
scattered in per-type completion functions and interactive mode
questionnaries. This is now driven by the option_info[] table.
In general, we do our best to just map the command line options to
properties and allow mixing them. For the rest there's the
check_and_set() callbacks (basically to keep compatibility with previous
nmcli versions). This this is now all possible:
$ nmcli c add type ethernet ifname '*'
This always worked
$ nmcli c add type bond-slave save no -- connection.autoconnect no
The "save" and "--" still work
$ nmcli c add connection.type ethernet ifname eth0
Properties can now be used
$ nmcli c add type ethernet ip4 1.2.3.4 mac 80:86:66:77:88:99 con-name whatever
There's no implementation mandated order of the properties (the type
still must be known to determine which properties make sense)
$ nmcli --ask c add type ethernet ip4 1.2.3.4 mac 80:86:66:77:88:99 con-name whatever
The interactive mode asks only for properties that weren't specified
on command line
This improves the HTML rendering.
But it also causes a lot of non-resolvable linkends warning when rendering a
separate manual pages into roff/mman. The messages are harmless, but still
a bit ugly.
