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().
Fix route manager not to delete externally added routes
but only routes that were previously added by route manager.
Also, add a test case and refactor the _exists() functions
to have them more useful.
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.
This is done to silence coverity. In the dispatcher the existence of the
key is checked before and we're fine with leaving the value untouched
in the vpn-plugin-old.
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.
Rename verify_master_for_slave(), since it does a lot more than just verifying
the master setting.
Make the type check optional and return the type of the connection that
matched. This makes it possible to omit setting the slave type on a command
line and still get the slave type right.
This separates setup of the master & slave type and addition of the wired
settings for "bond-slave", "bridge-slave" and "team-slave" connection types
from processing of slave type specific options.
A follow-up commit will make it possible to specify master (and slave type) for
any connection, not relying on "-slave" types.
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.
