NMPolicy only updates the NMDnsManager's hostname when it changes,
which previously did not include at startup. Meaning if your hostname
never changed, NMDnsManager would never learn it (and so would never
add an appropriate "search" line to resolv.conf). Fix that.
If NM is not explicitly managing resolv.conf (either due to the "dns"
NetworkManager.conf setting, or because resolv.conf is immutable),
then don't try to parse nameservers out of it when capturing a
connection, since there's no reason to believe that the name servers
there are related to any particular connection.
If /etc/resolv.conf has the immutable flag set, then behave as though
"dns=none" was specified (rather than repeatedly trying and failing to
update it).
Add a property indicating whether NMDnsManager is ignoring
resolv.conf, managing it by explicitly putting nameservers into it, or
managing it by proxying to another service (eg, dnsmasq) with
"nameserver 127.0.0.1".
NM bounces devices on suspend/resume, since some buggy drivers require
it. However, there's no need to take down virtual devices. (In
particular, we don't want to take down libvirt's virbr0, since it
won't get automatically brought back up afterward.)
NetworkManager was not correctly updating the DNSSL/RDNSS option timestamps
when new Router Advertisements were received, leading to a router solicitation
loop after 1/2 the lifetime of the DNSSL/RDNSS option.
A lifetime of 0 means that the domain or server should no longer
be used, so if we get an RA with a zero-lifetime DNS server or
domain that we haven't seen before, don't bother adding it to the
list.
DNS servers and domains that are already known and become zero
lifetime in the next RA are already correctly handled by
clean_dns_servers() and clean_domains().
The DNS server and domain timestamps and lifetimes weren't updated
when a new RA was received. When half the lifetime for either of
them had passed, clean_dns_servers() and clean_domains() request a
Router Solicitation to ensure the DNS information does not expire.
This obviously results in a new Router Advertisement, but since the
timestamps don't get updated, clean_dns_servers() and clean_domains()
simply request another solicitation because 'now' is still greater
than half the old lifetime. This casues another solicit request,
which causes another RA, which... etc.
https://bugzilla.redhat.com/show_bug.cgi?id=1044757https://bugzilla.gnome.org/show_bug.cgi?id=720760
Now that NMActiveConnection has IP and DHCP config info, use that
directly in "nmcli con show active" rather than getting it from the
connection's device; this way, we get the right info for VPN
connections as well.
Add IP and DHCP config properties to the D-Bus ActiveConnection
objects.
For device connections, this is redundant with the properties already
on the Device object, but for VPN connections, this information was
not previously available.
When a new activation request is received, NetworkManager creates a new
NMActiveConnection to track that request. The device may already be activated,
in which case NetworkManager stops the old activation and starts the new one,
but both exist in parallel for a short period of time. If the old
NMActiveConnection is activating and already has a pending 'activation'
action, when the new NMActiveConnection adds its own 'activating' action,
they will clash. This is fixed by making each NMActiveConnection's activation
pending action uniquely named.
This fixes a g_warning with the following back trace:
#0 0x000000328224edfd in g_logv () from /lib64/libglib-2.0.so.0
#1 0x000000328224efe2 in g_log () from /lib64/libglib-2.0.so.0
#2 0x000000328224f2e6 in g_warn_message () from /lib64/libglib-2.0.so.0
#3 0x0000000000440aee in nm_device_add_pending_action (device=0x14002e0, action=0x50704a "activation") at devices/nm-device.c:7172
#4 0x000000000047525c in nm_active_connection_set_device (self=0x141b3c0, device=0x14002e0) at nm-active-connection.c:364
#5 0x0000000000475ec1 in set_property (object=0x141b3c0, prop_id=11, value=0x7fff7ff36c20, pspec=0x1405f70) at nm-active-connection.c:647
#6 0x0000003282615d3e in g_object_newv () from /lib64/libgobject-2.0.so.0
#7 0x00000032826162e6 in g_object_new_valist () from /lib64/libgobject-2.0.so.0
#8 0x0000003282616654 in g_object_new () from /lib64/libgobject-2.0.so.0
#9 0x0000000000474193 in nm_act_request_new (connection=0x13bb0e0, specific_object=0x0, subject=0x1447740, device=0x14002e0) at nm-activation-request.c:376
#10 0x000000000048e477 in _new_active_connection (self=0x13e8060, connection=0x13bb0e0, specific_object=0x0, device=0x14002e0, subject=0x1447740, error=0x7fff7ff36f90) at nm-manager.c:2947
#11 0x000000000048ed77 in impl_manager_activate_connection (self=0x13e8060, connection_path=0x134d590 "/org/freedesktop/NetworkManager/Settings/9", device_path=0x134d550 "/org/freedesktop/NetworkManager/Devices/1",
specific_object_path=0x0, context=0x143a9b0) at nm-manager.c:3206
#12 0x00000000004876c8 in dbus_glib_marshal_nm_manager_VOID__BOXED_BOXED_BOXED_POINTER (closure=0x7fff7ff37220, return_value=0x0, n_param_values=5, param_values=0x1448830, invocation_hint=0x0,
marshal_data=0x48e9dd <impl_manager_activate_connection>) at nm-manager-glue.h:189
#13 0x0000003284a0d6a9 in object_registration_message () from /lib64/libdbus-glib-1.so.2
#14 0x000000348ea1ce66 in _dbus_object_tree_dispatch_and_unlock () from /lib64/libdbus-1.so.3
#15 0x000000348ea0fa31 in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#16 0x0000003284a0acc5 in message_queue_dispatch () from /lib64/libdbus-glib-1.so.2
#17 0x0000003282247df6 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#18 0x0000003282248148 in g_main_context_iterate.isra.22 () from /lib64/libglib-2.0.so.0
#19 0x000000328224854a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#20 0x000000000042c6c0 in main (argc=1, argv=0x7fff7ff379b8) at main.c:629
Signed-off-by: Thomas Haller <thaller@redhat.com>
Use a GSList of the string values, instead of an array of GQuarks.
Using GQuarks does not allow to add arbitrary strings, because they
would leak the internalized strings. The next patch will begin
using unique, non-const action strings.
Given the rather small number of expected pending states, a singly
linked list seems appropriate.
Signed-off-by: Thomas Haller <thaller@redhat.com>
(some fixes and simplifications by dcbw based on patch reviews)
Make clear, that only full names are guaranteed to work in future
versions. The use of some abbreviations might break as new options
get added.
It would be rather complicated, to ensure, that abbreviations always
continue to work, at the additional disadvantage, that they no longer
uniquely identify an option. Instead, clearly state that using
them is not guaranteed to work in the future. Users that care about
long term compatibility should instead spell out the full names.
Abbreviations are mainly here for interactive use.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Virtual device types can only have an ifname in the "Device" entry,
but the code was accidentally filling in the MAC address too if the
device currently existed (which then made the entry value invalid).
The nmtui development tree didn't use libtool, and the rules that
worked to install links in those Makefiles ended up causing the
libtool wrapper scripts to get installed here. Fix.
tui/vpn-helpers.c is not yet used, so it shouldn't be translated yet.
Having it in po/POTFILES fails distcheck because, since it is not
yet used, it's not distributed, and thus can't be found in the
distcheck build.
