Commit d51975e changed, that we treat assumed and non-assumed
connections the same with respect to the default route. This is
certainly wrong, if we have an nm-generated-assumed connection
at hand. In this case, NM just generated a connection based on what
was configured on the system. Looking at that result and re-enforcing
the default-route is wrong.
We want to manage the default-route for assumed, persistent connections.
If the connection was assumed and generated, we do not.
This commit reverts d51975ed for nm-generated-assumed connection and
restores the previous behavior.
https://bugzilla.redhat.com/show_bug.cgi?id=1244483
Fixes: d51975ed92
Rename "default_route.v4_configure_first_time" to "v4_commit_first_time".
For one, the name "commit" matches better to the @commit variable in ip4_config_merge_and_apply()
and ip6_config_merge_and_apply(). Then, we don't need this information
only for default-routes, so move the variable out of the @default_route
struct.
This makes wifi preferred to wwan (the modem and bluetooth device types
to be specific) by default, so that users that care about being
connected at all times can keep both enabled with auto-connect. As wifi
is usually unmetered and often faster than wwan, it makes sense to
prefer it. This is also how pretty much every smart-phone in the world
behaves, so it aligns better with user expectations too.
https://bugzilla.gnome.org/show_bug.cgi?id=744754
Now that we set hostname with systemd, call dispatcher in nm-settings.c.
gethostname() in nm-policy.c already sees the new hostname.
Fixes: 6dc35e66d4
Fixes: 6c3d71c431
Fixes:Beaker:NetworkManager_Test44_dispatcher_hostname
Remove nm_logging_syslog_closelog(). The reasons are:
- closelog() is optional according to the manual.
- we called nm_logging_syslog_closelog() at the end of the
main() function. But we have destructors running afterwards,
so we were closing the log before logging the last line.
Apparently that had no bad consequences either, so why was
closelog() even useful?
Also, it's hard to determine when we log the last line and
only closelog() afterwards.
- closelog() does not revert what openlog() did, this is ugly.
Whether NM runs in debug mode is also interesting to other
components outside of "main.c". Expose global_opt.debug
via a new nm_config_get_is_debug() function.
Actually, we should move parsing of all command line options
to NMConfig, as NMConfig is the central instance to provide
such information.
nm_config_data_get_value() returns an allocated string. This is inconvenient
for the caller. Add a utility function nm_config_data_get_value_cached() that
caches the returned value. Of course, use with care as the returned string
will be invalidated by each call to nm_config_data_get_value_cached().
In most cases, when syncing routes, we should only remove routes
that were configured by us previously. Otherwise, there is a race
that we can remove routes added externally.
Now, when applying IP configuration for a device, only do a full-sync
at the first time when we activate the device. Later on, only remove
routes that were added by us.
Add an argument @full_sync to the sync method of NMRouteManager.
@full_sync was what we did up to now, meaning, we removed every
route on the interface that was no on our internal list of known
routes.
Now with !@full_sync, only remove routes that were tracked previously.
This means, we will only remove routes that were added by us previously.
Don't make use of the new option yet. So there is no change of behavior
yet.
Coverity detected that it was always-true:
src/platform/nm-linux-platform.c:4035: dead_error_line: Execution cannot reach the expression "preferred != 0U" inside this statement: "if (lifetime != 0U || lifet...".
#0 0x00007ffff4200a98 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007ffff420272a in __GI_abort () at abort.c:89
#2 0x00007ffff4a372a5 in g_assertion_message (domain=domain@entry=0x5555557a0511 "NetworkManager", file=file@entry=0x5555557b201c "nm-ip4-config.c", line=line@entry=1458, func=func@entry=0x5555557b221b "nm_ip4_config_add_route", message=message@entry=0x555555b96a00 "assertion failed: (priv->ifindex)") at gtestutils.c:2356
#3 0x00007ffff4a3733a in g_assertion_message_expr (domain=0x5555557a0511 "NetworkManager", file=0x5555557b201c "nm-ip4-config.c", line=1458, func=0x5555557b221b "nm_ip4_config_add_route", expr=<optimized out>) at gtestutils.c:2371
#4 0x000055555567f414 in nm_ip4_config_add_route (config=0x555555c27f80 [NMIP4Config], new=0x7fffffffd378) at nm-ip4-config.c:1458
#5 0x000055555576b6d6 in add_ip4_vpn_gateway_route (config=0x555555c27f80 [NMIP4Config], parent_device=0x555555afeb80 [NMDeviceEthernet], vpn_gw=4240082129) at vpn-manager/nm-vpn-connection.c:522
#6 0x000055555576b3c3 in apply_parent_device_config (connection=0x7fffdc01a300 [NMVpnConnection]) at vpn-manager/nm-vpn-connection.c:910
#7 0x000055555576b197 in nm_vpn_connection_apply_config (connection=0x7fffdc01a300 [NMVpnConnection]) at vpn-manager/nm-vpn-connection.c:945
#8 0x0000555555769ada in nm_vpn_connection_config_maybe_complete (connection=0x7fffdc01a300 [NMVpnConnection], success=1) at vpn-manager/nm-vpn-connection.c:981
#9 0x000055555576c35f in nm_vpn_connection_ip4_config_get (self=0x7fffdc01a300 [NMVpnConnection], dict=0x555555c10150) at vpn-manager/nm-vpn-connection.c:1285
#10 0x0000555555766e2c in ip4_config_cb (proxy=0x555555acedd0 [GDBusProxy], dict=0x555555c10150, user_data=0x7fffdc01a300) at vpn-manager/nm-vpn-connection.c:1643
#11 0x00007ffff27f2db0 in ffi_call_unix64 () at ../src/x86/unix64.S:76
#12 0x00007ffff27f2818 in ffi_call (cif=cif@entry=0x7fffffffd870, fn=<optimized out>, rvalue=0x7fffffffd7d0, avalue=avalue@entry=0x7fffffffd770) at ../src/x86/ffi64.c:525
#13 0x00007ffff4d114f9 in g_cclosure_marshal_generic (closure=0x555555b67f20, return_gvalue=0x0, n_param_values=<optimized out>, param_values=0x555555a77220, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1448
#14 0x00005555556c824d in dbus_signal_meta_marshal (closure=0x555555b67f20, return_value=0x0, n_param_values=4, param_values=0x7fffffffdb50, invocation_hint=0x7fffffffdad0, marshal_data=0x555555b8aa60)
at ../libnm-core/nm-dbus-utils.c:95
#18 0x00007ffff4d2b29f in <emit signal ??? on instance 0x555555acedd0 [GDBusProxy]> (instance=instance@entry=0x555555acedd0, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3361
#15 0x00007ffff4d10cd5 in g_closure_invoke (closure=0x555555b67f20, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7fffffffdb50, invocation_hint=invocation_hint@entry=0x7fffffffdad0)
at gclosure.c:768
#16 0x00007ffff4d22539 in signal_emit_unlocked_R (node=node@entry=0x555555a46290, detail=detail@entry=0, instance=instance@entry=0x555555acedd0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffdb50) at gsignal.c:3549
#17 0x00007ffff4d2aef0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffdd50) at gsignal.c:3305
#19 0x00007ffff502ebac in on_signal_received (connection=<optimized out>, sender_name=0x7fffe00063e0 ":1.541", object_path=<optimized out>, interface_name=<optimized out>, signal_name=0x7fffe0016f80 "Ip4Config", parameters=0x555555c22330, user_data=0x7fffdc00e850) at gdbusproxy.c:917
#20 0x00007ffff501e8b4 in emit_signal_instance_in_idle_cb (data=0x7fffe0016a60) at gdbusconnection.c:3753
#21 0x00007ffff4a10a8a in g_main_context_dispatch (context=0x555555a23360) at gmain.c:3122
#22 0x00007ffff4a10a8a in g_main_context_dispatch (context=context@entry=0x555555a23360) at gmain.c:3737
#23 0x00007ffff4a10e20 in g_main_context_iterate (context=0x555555a23360, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808
#24 0x00007ffff4a11142 in g_main_loop_run (loop=0x555555a23420) at gmain.c:4002
#25 0x00005555555b7e7b in main (argc=1, argv=0x7fffffffe3b8) at main.c:484
https://bugzilla.gnome.org/show_bug.cgi?id=752225
It is wrong to only consider internal_gateway of the VPN connection.
Instead, we must first set the gateway of NMIP4Config and then overwrite
it with the connection settings.
For non-tunnel based VPNs (openswan, libreswan), we must
clear the gateway setting. The default route is managed
by NMDefaultRouteManager, and we must not overwrite the
gateway of the parent device.
This fixes a bug if the VPN connection specifies a gateway, it
would have overwritten the gateway of the underlying device.
The gateway property of NMIP4Config/IP6Config determines the next hop
for the default route. That is different from the @external_gw property
of the VPN which is the address of the world-reachable VPN gateway.
It is wrong to set the gateway of the VPN's IP config to the external gateway.
This causes ip4_config_merge_and_apply() to overwrite the gateway of the
underlying device.
Instead, NMDefaultRouteManger gets the gateway directly from the VPN
connection by quering nm_vpn_connection_get_ip4_internal_gateway().
When a VPN has no default route, it is wrong to enforce the absence
of a default route on that device. Instead, if there is no default
route, NMDefaultRouteManager should just forget about the route.
This is especially important, because for VPN types like openswan
there is no distinct tunnel interface. Instead, it shares the ifindex
with the parent-device.
Note that devices usually only enforce their default-route for a short
time and afterwards switch to non-synced. If that happens and there
is a VPN that enforces the absense of the default route on that device,
we end up deleting the default route.
Add an assert (g_return_val_if_reached()) that the interface name is
valid and shorter then 16 bytes. If it happened to be longer, strncpy()
would not have zero terminated the interface name.
The compatibily wrapper for rtnl_addr_flags2str() did not
behave identical because libnl adds a trailing ',' if it
encounters unknown attributes.
Also add test cases.
