#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.
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.
We don't really know which version it's going to be -- and thus if we're going
to actually need it (version 5), or not (version 4). It's going to be decided
at configure time.
Also, drop the bogus Fedora 19 conditionals; Fedora < 20 has ModemManager that's
too old for the WWAN code anyway.
make[4]: Entering directory './NetworkManager/src'
CC libsystemd_nm_la-util.lo
systemd/src/basic/util.c: In function 'cunescape_length_with_prefix':
systemd/src/basic/util.c:1271:30: error: 'u' may be used uninitialized in this function [-Werror=maybe-uninitialized]
t += utf8_encode_unichar(t, u);
^
systemd/src/basic/util.c:1230:26: note: 'u' was declared here
uint32_t u;
^
NetworkManager uses wpa_supplicant, which in turn calls OpenSSL for verifying
certificates. wpa_supplicant calls
SSL_CTX_load_verify_locations(ctx, CAfile, CApath)
using its ca_cert and ca_path options as CAfile and CApath parameters.
We have a configure time option with_system_ca_path to override ca_path.
However, it doesn't work when a system (like Fedora) only uses bundled PEM
certificates instead of a directory with hashed certificates ([1], [2]).
So this commit allows setting --with_system_ca_path to a file name (the
trusted certificate bundle). Then the name is used to populate wpa_supplicant's
ca_cert instead of ca_path.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1053882
[2] https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/https://bugzilla.redhat.com/show_bug.cgi?id=1236548
priv->iface could change in device_link_changed() which reacts on platform link
changes caused by nm_platform_link_set_user_ipv6ll_enabled(). (The variable could
change between obtaining and using its value, because emitting a glib signal runs
callbacks synchronously).
Actually, the problem is already fixed by commit 04caae735f.
But still this is better.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1224366
Kernel does not allow to add the same route (as determined by network/plen,metric)
on two different interfaces (ifindex). In case of conflict, NMRouteManager used to
ignore any but the firstly added route.
On the other hand, we cannot add a gateway-route, if there is no direct
route to the gateway. Hence, skipping duplicate routes can mean that we
skip a direct route what was necessary to add another gateway-route,
which then leads to a failure to add that route.
This also applies to IPv4 device routes that since recently are managed
by NMRouteManager.
For example, say you connect two interfaces to the same IP subnet.
The route-metric can conflict if the interfaces are of the same type
or if the user explicitly configured a conflict.
In case of conflicts, NMRouteManager would only configure the first
appearing route and skip the shadowed route on the second interface.
Now we cannot configure gateway-routes on the second interface because
the gateway is unreachable.
There are many scenarios where this issue can happen, especially with
default-routes and user-configured-routes.
For example with default-routes, ip4_config_merge_and_apply() would check
if the default-gateway requires an explict route and possibly add it.
But then NMRouteManager might not add the route because it is shadowed
by a route on an other interface.
This patch solves the issue by having NMRouteManager configure shadowed
routes too, similar to what NMDefaultRouteManager does.
It does that by searching for an unused, non-conflicting, higher metric
for the route, i.e. bump the metric by 1 until we can add it without
conflict.
Also note that NMRouteManager still ensures that for conflicting routes
the best route sticks to the interface that configured it first. That
means if you later add the conflicting route on another interface, it
will be added with higher metric and the data is still routed along the
first interface.
