Lease expiry means that the DHCP configuration is no longer valid, and
that all attempts to renew/rebind the lease have failed. The IP config
needs to be removed. NetworkManager also sets prefered/valid lifetimes
on addresses, so the kernel will remove them when the lease expires
anyway. That causes removal of the default route, if the default route
was through the device whose config has now expired.
DHCP clients will typically move to the 'renew' or 'rebind' states when
nearing lease expiry, then if no answer is received move to the 'expire'
state. Eventually they move to the 'fail' state when all attempts to
contact the server have failed.
Previously, since NM ignored the 'expire' DHCP state it would not clear
out the DHCP IP4 config immediately when the lease expired, instead
waiting for the DHCP client to move to the 'fail' state. But if the
DHCP server appeared between the 'expire' and 'fail' states, NM would
not notice and the device's NMIP4Config would not change, and thus the
Policy would not get the "ip4-config-changed" signal to re-add the
default route that the kernel had previously removed due to the valid
lifetime reaching zero when the lease expired.
https://bugzilla.redhat.com/show_bug.cgi?id=1139326
If DHCP fails to renew or rebind a lease, fail the device since the
IP config is no longer valid. Commit e2b7c482 was actually wrong for
dhcp[4|6]_fail(), since (ip_state == IP_FAIL) will never be true if
DHCP has ever been started, as IP_FAIL is only set from
nm_device_activate_ip[4|6]_config_timeout(), which obviously will not
be called in DHCP code paths if DHCP has previously succeeded.
A device (e.g. of type tun) might not have a hwaddr. Avoid the assertion
in nm_utils_hwaddr_matches().
Backtrace:
#0 0x00007fd0920444e9 in g_logv (log_domain=0x5a5be3 "libnm", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff2551e590) at gmessages.c:989
#1 0x00007fd09204463f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1025
#2 0x0000000000555d31 in nm_utils_hwaddr_matches (hwaddr1=0x7fff2551e6a0, hwaddr1_len=6, hwaddr2=0x0, hwaddr2_len=-1) at ../libnm-core/nm-utils.c:2414
#3 0x000000000049e7a0 in have_connection_for_device (self=0x7fd084008710, device=0x168e5c0) at settings/nm-settings.c:1513
#4 0x000000000049e23d in nm_settings_device_added (self=0x7fd084008710, device=0x168e5c0) at settings/nm-settings.c:1599
#5 0x00000000004e6447 in add_device (self=0x1654150, device=0x168e5c0, try_assume=1) at nm-manager.c:1840
#6 0x00000000004e8fb6 in platform_link_added (self=0x1654150, ifindex=6, plink=0x165c328, reason=NM_PLATFORM_REASON_INTERNAL) at nm-manager.c:2163
#7 0x00000000004e3252 in platform_link_cb (platform=0x15b1870, ifindex=6, plink=0x165c328, change_type=NM_PLATFORM_SIGNAL_ADDED, reason=NM_PLATFORM_REASON_INTERNAL, user_data=0x1654150) at nm-manager.c:2178
#8 0x000000381dc05d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#9 0x000000381dc056bc in ffi_call (cif=cif@entry=0x7fff2551ed00, fn=0x4e31e0 <platform_link_cb>, rvalue=0x7fff2551ec70, avalue=avalue@entry=0x7fff2551ebf0) at ../src/x86/ffi64.c:522
#10 0x00007fd092331ad8 in g_cclosure_marshal_generic (closure=0x1607710, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454
#11 0x00007fd092331298 in g_closure_invoke (closure=0x1607710, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7fff2551ef00, invocation_hint=invocation_hint@entry=0x7fff2551eea0)
at gclosure.c:777
#12 0x00007fd09234335d in signal_emit_unlocked_R (node=node@entry=0x15b03a0, detail=detail@entry=0, instance=instance@entry=0x15b1870, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff2551ef00) at gsignal.c:3586
#13 0x00007fd09234b0f2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff2551f0e0) at gsignal.c:3330
#14 0x00007fd09234b3af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3386
#15 0x000000000048353d in nm_platform_query_devices () at platform/nm-platform.c:345
#16 0x00000000004e12d2 in nm_manager_start (self=0x1654150) at nm-manager.c:4170
#17 0x000000000044349a in main (argc=1, argv=0x7fff2551f938) at main.c:661
Fixes: b019348fdd
Signed-off-by: Thomas Haller <thaller@redhat.com>
Since we already intenalize the @tag to a GQuark, just use
the constant string, instead of duplicating the string.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Let the user completly disable polkit authentication by
building NM with configure option '--enable-polkit=disabled'.
In that case, configuring 'main.auth-polkit=yes' will fail all
authentication requests (except root-requests, which are always granted).
This reduces the size of the NetworkManager binary by some 26KB (16KB
stripped).
Signed-off-by: Thomas Haller <thaller@redhat.com>
This makes NetworkManager independent of <polkit/polkit.h>
development headers and libpolkit-gobject-1.so library.
Instead communicate directly with polkit using its DBUS
interface.
PolicyKit support is now always compiled in. You can control
polkit authorization with the configuration option
[main]
auth-polkit=yes|no
If the configure option is omitted, a build time default
value is used. This default value can be set with the
configure option --enable-polkit.
This commit adds a new class NMAuthManager that reimplements the
relevant DBUS client parts. It takes source code from the polkit
library.
https://bugzilla.gnome.org/show_bug.cgi?id=734146
Signed-off-by: Thomas Haller <thaller@redhat.com>
Allow for the special values "1" and "0". Also, ignore the
letter case when comparing the configuration value.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When a connection is updated by Update() and the new settings contain *no*
secrets, leave the previous secrets untouched. This makes updating connection
parameters much easier. Users (clients) need not to bother with secrets when
they only want adjust a parameter.
Use case:
- GetSettings()
- modify the settings
- Update()
E.g. nmcli con mod my-wifi connection.zone home
https://bugzilla.gnome.org/show_bug.cgi?id=728920
vxlan_info_data_parser() must take care of missing netlink attributes.
Otherwise, older kernels will crash NM.
Also, workaround compilation against old kernel headers which are
missing 'struct ifla_vxlan_port_range'. We do this by defining our
own 'struct nm_ifla_vxlan_port_range' version.
Reported-by: Javier Jardón <jjardon@gnome.org>
Signed-off-by: Thomas Haller <thaller@redhat.com>
For PAN devices we create an unsaved connection if no matching
connection exists. After the device gets removed, we want to clean
up that connection, unless it was modified/saved in the meantime.
Before this was accomplished by creating a clone of the original
connection. When deciding whether the temporary connection was
modified, we would compare the current state with the original.
This can now be simplified, because we have the nm-generated flag
that gets cleared whenever the user modifies or saves the connection.
This code is also more robust, because the previous implementation
was a hack, but could not reliably detect whether the connection
was modified by the user.
Signed-off-by: Thomas Haller <thaller@redhat.com>
At a few places, we checked for nm_device_uses_generated_connection()
whether to touch the device or not. nm_device_uses_generated_connection() used
to look at the "nm-generated" property of the NMSettingsConnection.
We are about to change the meaning of "nm-generated", which will mean
"any connection generated by NM, for whatever reason".
Instead now use the new "nm-generated-assumed" connection flag that has
the meaning "nm-generated" used to have.
So rename nm_device_uses_generated_connection() to nm_device_uses_generated_assumed_connection()
which looks at the "nm-generated-assumed" flag instead.
Also, be more strict in nm_device_uses_generated_assumed_connection() to require
both an "nm-generated-assumed" connection *and* an active connection that is
nm_active_connection_get_assumed().
Signed-off-by: Thomas Haller <thaller@redhat.com>
NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED_ASSUMED is a special kind of
NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED, that was generated for
connection assumption.
At the moment, the flag is used identical to NM_GENERATED. Later,
NM_GENERATED will get a slightly different meaning.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before, NMSettingsConnection had two internal properties 'unsaved' and
'nm-generated'. Now, implement these properties as #NMSettingsConnectionFlags.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Deleting an IPv4 address using libnl requires the proper peer address.
Pass the address of the peer on to nm_platform_ip4_address_delete().
Signed-off-by: Thomas Haller <thaller@redhat.com>
Seems like 128k is not enough for systems with many interfaces. This adds 4k
per device, while keeping the 128k minimum. Therefore this change only
affects systems with more than 32 interfaces.
https://bugzilla.redhat.com/show_bug.cgi?id=1141256
Port libnm-core/libnm to GDBus.
The NetworkManager daemon continues to use dbus-glib; the
previously-added connection hash/variant conversion methods are now
moved to NetworkManagerUtils (along with a few other utilities that
are now only needed by the daemon code).
In preparation for porting to GDBus, make nm_connection_to_dbus(),
etc, represent connections as GVariants of type 'a{sa{sv}}' rather
than as GHashTables-of-GHashTables-of-GValues.
This means we're constantly converting back and forth internally, but
this is just a stepping stone on the way to the full GDBus port, and
all of that code will go away again later.
libnm-util's connection deserializing/copying/replacing functions have
odd semantics where sometimes they both modify a connection AND return
an error. libnm-core tried to improve things by guaranteeing that the
connection would not be modified if the new settings were invalid, but
this ended up breaking a bunch of places that needed to be able to
work with invalid connections. So re-fix the functions by reverting
back to the old semantics, but having return values that clearly
distinguish whether the connection was modified or not.
For comparison:
- nm_connection_new_from_hash() / nm_simple_connection_new_from_dbus():
- libnm-util: returns a valid connection or NULL.
- OLD libnm-core: returned a valid connection or NULL.
- NEW libnm-core: returns a valid connection or NULL.
- nm_connection_duplicate() / nm_simple_connection_new_clone():
- libnm-util: always succeeds, whether or not the connection is
valid.
- OLD libnm-core: returned a valid connection or NULL
- NEW libnm-core: always succeeds, whether or not the connection
is valid.
- nm_connection_replace_settings_from_connection():
- libnm-util: always replaces the settings, but returns FALSE if
the connection is now invalid.
- OLD libnm-core: either replaced the settings and returned TRUE
(if the settings were valid), or else left the connection
unchanged and returned FALSE (if not).
- NEW libnm-core: always replaces the settings, and has no
return value. (The modified connection is valid if and only if
the replaced-from connection was valid; just like with the
libnm-util version.)
- nm_connection_replace_settings():
- libnm-util: returns TRUE if the new settings are valid, or
FALSE if either (a) the new settings could not be deserialized
and the connection is unchanged, or (b) the new settings were
deserialized, and the connection was updated, but is now not
valid.
- OLD libnm-core: either replaced the settings and returned TRUE
(if the settings were valid), or else left the connection
unchanged and returned FALSE (if not).
- NEW libnm-core: returns TRUE if the connection was updated
(whether or not it is valid), or FALSE if the new settings
could not be deserialized and the connection is unchanged.
UINT is just 32bit, truncating the GType on 64-bit platforms. We do already use
cast to SIZE, which is as wide as a pointer, when we need a GType in another
place (nmtui); let's do it here as well.
Broken by [0bc1b5138] core: add support for internal device factories
https://bugzilla.gnome.org/show_bug.cgi?id=736780
DHCP client may be killed by SIGPIPE when attempting to write to a broken pipe.
This can be observed, for example, when journald is restarted.
Fix that by redirecting both stdout and stderr to /dev/null. The client logs
into syslog anyway. When NetworkManager is run with '--debug' we duplicate
syslog to stderr, so the messages goes to terminal as well.
Testcase:
- start a NetworkManager service by systemd
- activate an DHCP ethernet connection
- sudo systemctl restart systemd-journald.service
- reactive the ethernet connection (nmcli con up <my-eth>)
- DHCP client is killed by SIGPIPE right after its startup:
<info> (enp0s25): DHCPv4 client pid 13959 exited with status -1
<warn> DHCP client died abnormally
Another possible fix would be ignoring SIGPIPE in the DHCP client as it is not
useful in most cases. E.g. systemd ignores SIGPIPE for its services, by
default:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=353e12c2f4a9e96a47eb80b80d2ffb7bc1d44a1bhttps://bugzilla.gnome.org/show_bug.cgi?id=735962
