When a full section is specified as the field parameter in terse tabular
mode, the section name should be printed followed by all the field values
belonging to that section separated by ':'. The NAME of section CONNECTIONS
was missing.
sample command:
$ nmcli -m tab -t -f CONNECTIONS device show ens3
previous output was:
/org/freedesktop/NetworkManager/Settings/{1}:5059XXX-XXXX.. | ens3-dhcp
now:
CONNECTIONS:/org/freedesktop/NetworkManager/Settings/{1}:5059XXX-XXXX.. | ens3-dhcp
When only the main header should be printed and output mode
is 'pretty' skip the construction of the string containing
field values as it will not be used.
Don't print value output in the "PRETTY" format when the --terse option
has been specified.
This should allow to feed back the output from "nmcli show" to "nmcli
modify" without changes.
It turns out that some routers return responses to DHCP6
Information-request messages that do not contain any of the options
that we insert in the "options" table. When that happened and the
info-only flag for DHCP6 was set, the assertion was triggered and
NetworkManager crashed. We remove the assertion as having empty options
is a possibility and is harmless anyway. This happened while using the
internal dhclient.
Perform the lookup for a matching device earlier, so that in
autoconnect_slaves() we already know which device a connection is
being activated on. This will be needed to sort the returned
connections by interface name.
We should try to guarantee a stable activation order of connections
across reboots; this is required, for example, for bonds because they
get assigned the MAC address of the first device enslaved, and thus
changing the activation order of slaves means also changing the MAC
address of the bond. Since we activate connections in the order links
are discovered, having a stable sorting of links returned by platform
is enough.
The ifindex of interfaces can change between reboots as it depends on
the order in which kernel discover interfaces. Provided that the
system uses a mechanism to enforce persistent interface naming (as
udev rules or systemd-udevd predictable names), and that NM starts
after all interfaces have been announced by udev, using the interface
name instead of ifindex will guarantee a consistent order.
When slave connections are autoactivated as dependency to master we
don't check if a compatible device is available before trying to
activate them, leading to the following failed assertion:
nm_act_request_new: assertion 'NM_IS_DEVICE (device)' failed
When dhcp hostname-mode is selected, NetworkManager will just update the
hostname with information available from DHCP (if any).
So, when a connection providing a DHCP host-name option is brought up we
update the transient hostname. When it is later teared down, this will
trigger NetworkManager to update the hostname: this time no DHCP host-name
option will be found and so the hostname will not be changed, keeping
the obsoleted one from the disappeared DHCP option.
In order to fix this we have to keep track if the last hostname set was
retrieved from the DHCP host-name option: in this case NetworkManager
will be able to reset it by applying back the previous hostname.
When updating the hostname we can now detect if someone else changed
the hostname: if so, search for hostname candidates in the dhcp
configuration but avoid to fallback to the hostname saved when NM
started or querying dns for a reverse lookup of the current IP.
As we try to set the hostname through dbus, we should also try to
retrieve current hostname value from dbus first: otherwise we may end
retrieving the "old" hostname via gethostname while the dbus hostnamed
updated is pending.
If the IP setting does not exist, consider the IP method as
may-fail=yes. This simplifies the decision path in check_ip_state(),
where the value of may-fail is used to decide whether we must wait for
the IP method to complete. If there is no IP setting (i.e. the device
is a slave), we don't have to wait for it to be applied.
Fixes the following:
nm_setting_ip_config_get_may_fail: assertion 'NM_IS_SETTING_IP_CONFIG (setting)' failed
Process terminating with default action of signal 5 (SIGTRAP): dumping core
at 0x6C95643: g_logv (gmessages.c:1086)
by 0x6C957BE: g_log (gmessages.c:1119)
by 0x193CB3: nm_setting_ip_config_get_may_fail (nm-setting-ip-config.c:2336)
by 0x2431D0: check_ip_state (nm-device.c:4643)
by 0x24770B: nm_device_activate_stage3_ip6_start (nm-device.c:7594)
by 0x247EC7: nm_device_master_enslave_slave (nm-device.c:1769)
by 0x8659DCB: ffi_call_unix64 (unix64.S:76)
by 0x86596F4: ffi_call (ffi64.c:522)
by 0x6801147: g_cclosure_marshal_generic (gclosure.c:1487)
by 0x6800907: g_closure_invoke (gclosure.c:801)
by 0x6812A1C: signal_emit_unlocked_R (gsignal.c:3627)
by 0x681AAB0: g_signal_emit_valist (gsignal.c:3383)
by 0x681AD9E: g_signal_emit (gsignal.c:3439)
by 0x241F04: _set_state_full (nm-device.c:12272)
by 0x248E86: activate_stage3_ip_config_start (nm-device.c:7626)
by 0x227D83: activation_source_handle_cb (nm-device.c:4204)
by 0x227E3D: activation_source_handle_cb4 (nm-device.c:4141)
by 0x6C8ED79: g_main_dispatch (gmain.c:3152)
by 0x6C8ED79: g_main_context_dispatch (gmain.c:3767)
by 0x6C8F0B7: g_main_context_iterate.isra.24 (gmain.c:3838)
by 0x6C8F389: g_main_loop_run (gmain.c:4032)
by 0x139A80: main (main.c:425)
Adds NM_DEVICE and NM_CONNECTION tags to journal in various places.
When we're well covered, we can add hints to inspect relevant logs
to the client (which this merge does not).
https://bugzilla.gnome.org/show_bug.cgi?id=779536
Previously, the daemon would just use syslog with LOG_PERROR when run with
--debug option, even when actually configured to log into the journal.
Let's respect the configuration, but preserve the logging to stderr.
Works by dumb luck for in-tree build, because the .deps files that are
meant for the distribution happen to be the builddir. The out-of-tree
builds would generate an empty file.
nm_utils_exp10() is a better name, because it reminds of the function
exp10() from <math.h> which has a similar purpose (but whose argument
is double, not gint16).
"build_clean.sh" is used to generate a distribution tarball. The tarball
contains pregenerated man pages with default values for paths, which in
turn depend on the configure options when creating the tarball.
Previously, the man page would have paths like "usr/local/etc/NetworkManager/...",
which doesn't seem the best choice for a default man page.
Explicitly set the installation paths.
Also, --disable-dependency-tracking in this mode. It may speed up the
build.
We also dist libnm/nm-property-docs.xml, so depending on
whether we build from git or source tarball, the file
is in $(srcdir) or $(builddir).
Fixes: d7ad13591b
