delta/NetworkManager.git, branch th/route-full-sync

routes: fix race synching routes by not doing full-sync

2015-07-13T18:05:50+00:00

In most cases, when synching routes, we should only remove routes
that were configured by us previously. Otherwise, there is a race
that we can remove routes added externally.

routes/trival: add argument @routes_full_sync to IP config commit

2015-07-13T18:05:50+00:00

The argument is still unused, so no behavioral change yet.

route-manager: add argument to to only remove routes that were added by NMRouteManager

2015-07-13T18:05:50+00:00

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.

route-manager/trivial: fix naming of local variable

2015-07-13T17:15:05+00:00

vpn: merge branch 'th/vpn-route-bgo752225'

2015-07-13T13:30:42+00:00

https://bugzilla.gnome.org/show_bug.cgi?id=752225

vpn: fix creating config for non-tunnel based VPN connections

2015-07-13T13:05:49+00:00

    #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=) 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=, 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=, param_values=0x555555a77220, invocation_hint=, 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  (instance=instance@entry=0x555555acedd0, signal_id=, 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=, signal_id=, detail=, var_args=var_args@entry=0x7fffffffdd50) at gsignal.c:3305
    #19 0x00007ffff502ebac in on_signal_received (connection=, sender_name=0x7fffe00063e0 ":1.541", object_path=, interface_name=, 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=) 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

vpn: allow overwriting default gateway by connection configuration

2015-07-13T13:05:47+00:00

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.

vpn: fix overwriting gateway of parent device for non-tunnel based VPNs

2015-07-13T11:39:34+00:00

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.

vpn: don't set the gateway of VPN's IP config to the external gateway

2015-07-13T11:39:34+00:00

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().

default-route-manager: fix handling for absent default routes for VPN

2015-07-13T11:39:33+00:00

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.