Actually handle this new parameter in the nm-dispatcher process, setting
the value of a new CONNECTIVITY_STATE environment variable accordingly.
This patch also includes new tests to check the different cases.
https://bugzilla.gnome.org/show_bug.cgi?id=768969
In order to pass the connectivity state to the relevant hooks along with
the event itself, we need to add this parameter for the 'Action' method
of then internal 'org.freedesktop.nm_dispatcher' interface, which will
be sent by the network manager main process to the dispatcher.
https://bugzilla.gnome.org/show_bug.cgi?id=768969
It can go away before the activation finishes:
(process:378): GLib-GObject-WARNING **: instance with invalid (NULL) class pointer
Thread 1 "lt-nmcli" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff4fa919b in g_logv () from /lib64/libglib-2.0.so.0
(gdb) bt
#0 0x00007ffff4fa919b in g_logv () at /lib64/libglib-2.0.so.0
#1 0x00007ffff4fa930f in g_log () at /lib64/libglib-2.0.so.0
#2 0x00007ffff529b3ea in g_type_check_instance () at /lib64/libgobject-2.0.so.0
#3 0x00007ffff528fa94 in g_signal_handlers_disconnect_matched () at /lib64/libgobject-2.0.so.0
#4 0x000000000041ae4e in activate_connection_info_finish (info=0x7b5490) at connections.c:2197
#5 0x00007ffff5279470 in g_cclosure_marshal_VOID__OBJECTv () at /lib64/libgobject-2.0.so.0
#6 0x00007ffff5276617 in _g_closure_invoke_va () at /lib64/libgobject-2.0.so.0
#7 0x00007ffff5290ea9 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#8 0x00007ffff52914ff in g_signal_emit () at /lib64/libgobject-2.0.so.0
#9 0x00007ffff52763e8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#10 0x00007ffff52884a2 in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#11 0x00007ffff529112d in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#12 0x00007ffff52919ab in g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0
#13 0x00007ffff78fc9b1 in deferred_notify_cb (data=<optimized out>) at nm-object.c:243
#14 0x00007ffff4fa2703 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#15 0x00007ffff4fa2ab0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#16 0x00007ffff4fa2dd2 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#17 0x00000000004146e3 in main (argc=<optimized out>, argv=<optimized out>) at nmcli.c:618
(gdb) print info->device
If both IPv4 and IPv6 are enabled and IPv6 terminates first (and
ipv4.may-fail=yes), the device becomes ACTIVATED and we try to update
the system hostname from the DHCP lease, if necessary. But later, the
termination of DHCPv4 doesn't trigger a new update and so it's
possible that the system hostname remains unset even if the DHCPv4
lease specifies a hostname.
To have a deterministic behavior we should always try to update the
system hostname when a DHCP transaction terminates.
https://bugzilla.redhat.com/show_bug.cgi?id=1356015
Unfortunately teamd doesn't have an asynchronous way to notify a
change in the actual configuration, so when a port is enslaved or
released we wait some time for the changes to take effect and read the
configuration again.
https://bugzilla.redhat.com/show_bug.cgi?id=1310435
Request the actual configuration when reading it from teamd. The
actual configuration, differently from the normal one, doesn't contain
non-active team ports.
Virtual devices don't have a valid permanent hw address: when activating
a connection against a specific interface, a check is performed on the
device MAC address too: if it is an empty string, give a try to the
currently assigned MAC address.
enables (back) matching against 802-3-ethernet.mac-address and
802-3-ethenet.mac-address-blacklist connection parameters
for MAC addresses belonging to virtual devices too.
Even when there's no <secret>-flags key for it in vpn-data.
This is essentially to fix regression in the way openconnect uses the VPN
secrets:
Openconnect auth helper is essentially a web browser that fills in an arbitrary
HTML (or XML) form that's used to get the session cookie. The actual secret the
service needs is the cookie itself.
However, what needs to be remembered includes the form data. What data can be
in the form is installation dependent and can not be known in advance. Thus the
flags for it can't be currently set in the connection. The auth helper is not
capable of setting the flags either, because it can only return secrets.
Prior to 1424f249e we treated vpn.secrets without the flags as system secrets
and store them in the connection. Since that commit we just filter them away,
which broke user configurations.
This restores the behavior or treating everyting in vpn.secrets as secrets and
falling back to system secrets.
Another way would be to find a way to flag the secrets, perhaps by
extending the auth helper protocol to be able to store non-secret
properties too.
https://bugzilla.gnome.org/show_bug.cgi?id=768737
