The new flags are not yet used, so there is no change in functionality.
The flags NM_IP_CONFIG_MERGE_NO_ROUTES and NM_IP_CONFIG_MERGE_NO_DNS go
together with the 'ignore-auto-routes' and 'ignore-auto-dns' setting.
Note that for IPv4, NM_IP_CONFIG_MERGE_NO_DNS also ignores NIS, WINS, and dns-options.
This is different from current other places that handle 'ignore-auto-dns'
and only care about nameservers, domains, and searches.
Use NMVpnPluginInfo to load the plugins in NMVpnManager.
This has the advantage of reusing the code from libnm
to use the same approach to read the plugin config files.
Another advantage is that we now check the file permissions
of the config file.
Create a GDBusProxy for the service to be monitored and use that to
tell whether it is running, rather than using NMDBusManager and the
global NameOwnerChanged signal.
Move D-Bus export/unexport handling into NMExportedObject and remove
type-specific export/get_path methods (export paths are now specified
at the class level, and NMExportedObject handles the counters for all
exported types automatically).
Since all exportable objects now use the same get_path() method, we
can also add some helper methods to simplify get_property()
implementations for object-path and object-path-array properties.
Add NMExportedObject, make it the base class of all D-Bus-exported
types, and move the nm-properties-changed-signal logic into it. (Also,
make NMSettings use the same properties-changed code as everything
else, which it was not previously doing, presumably for historical
reasons).
(This is mostly just shuffling code around at this point, but
NMExportedObject will be more important in the gdbus port, since
gdbus-codegen doesn't do a very good job of supporting objects that
export multiple interfaces [as each NMDevice subclass does, for
example], so we will need more glue/helper code in NMExportedObject
then.)
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
#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().
The VPN connection requests secrets a few times; first it retrieves
only system-owned secrets to see if they are sufficient (and thus
doesn't need to bother the user), then it retrieves existing agent
owned secrets (so the user doesn't get a popup), then finally if
those aren't sufficient it asks the user interactively.
But if there was some error retrieving system secrets, or if there
weren't any system secrets at all, don't fail the VPN connection.
Just go on and ask the user for the secrets.
Most nm_platform_*() functions operate on the platform
singleton nm_platform_get(). That made sense because the
NMPlatform instance was mainly to hook fake platform for
testing.
While the implicit argument saved some typing, I think explicit is
better. Especially, because NMPlatform could become a more usable
object then just a hook for testing.
With this change, NMPlatform instances can be used individually, not
only as a singleton instance.
Before this change, the constructor of NMLinuxPlatform could not
call any nm_platform_*() functions because the singleton was not
yet initialized. We could only instantiate an incomplete instance,
register it via nm_platform_setup(), and then complete initialization
via singleton->setup().
With this change, we can create and fully initialize NMPlatform instances
before/without setting them up them as singleton.
Also, currently there is no clear distinction between functions
that operate on the NMPlatform instance, and functions that can
be used stand-alone (e.g. nm_platform_ip4_address_to_string()).
The latter can not be mocked for testing. With this change, the
distinction becomes obvious. That is also useful because it becomes
clearer which functions make use of the platform cache and which not.
Inside nm-linux-platform.c, continue the pattern that the
self instance is named @platform. That makes sense because
its type is NMPlatform, and not NMLinuxPlatform what we
would expect from a paramter named @self.
This is a major diff that causes some pain when rebasing. Try
to rebase to the parent commit of this commit as a first step.
Then rebase on top of this commit using merge-strategy "ours".
Of special note is the new D-Bus rule to allow root to talk to
org.freedesktop.NetworkManager.VPN.Plugin, without which NetworkManager
would not hear signals from the VPN plugins. Oddly, this worked
fine with dbus-glib...
https://bugzilla.gnome.org/show_bug.cgi?id=745307
No functional change, a cosmetic thing for now.
We want it set before any routes are added and ensure routes have a valid
ifindex before we pass it to the platform.
In a future NMRouteManager will need to look up the route for a device in
its cache thus we'll need to make sure routes passed to the it have an
appropriate ifindex set.
No functional change, a cosmetic thing for now.
We want it set before any routes are added and ensure routes have a valid
ifindex before we pass it to the platform.
In a future NMRouteManager will need to look up the route for a device in
its cache thus we'll need to make sure routes passed to the it have an
appropriate ifindex set.
Create a NMRouteManager singleton.
Refactor, no functional changes apart from change of log domain from
LOGD_PLATFORM to LOGD_CORE.
Subsequent commit will keep track of the conflicting routes, avoid overwriting
older ones with newer ones and apply the new ones when the old ones go away.
Add nm_utils_setpgid() as a g_spawn*() child setup function for
calling setpgid(), and use it where appropriate rather than
reimplementing it every time.
Replace the pthread_sigwait()-based signal handling with
g_unix_signal_add()-based handling, and get rid of all the
now-unnecessary calls to nm_unblock_posix_signals() when spawning
subprocesses.
As a bonus, this also fixes the "^C in gdb kills NM too" bug.
Also move the initilization of the instance into the constructed()
method.
NMAgentManager now owns a reference to the DBUS manager and Auth
manager and the dispose() function properly unregisters itself from
both.
We recently changed default values for route metrics. Revise that
again and increase the space between the default values.
No strong reason to do this, but it seems better to have larger
gaps and make use of the available range.
The parent device is just the device that happens to be the best device.
It does not mean, that its route metric should be inherited to the VPN
connection.
This also makes the resulting route metric for VPN connections much
more predictable: now it is either ipv4.route-metric from the connection,
or it falls back to NM_VPN_ROUTE_METRIC_DEFAULT (10).
For IPv4 addresses, the kernel automatically adds a route when
configuring an IP address. Unfortunately, there is no way to control
this behavior or to set the route metric.
Fix this, by adding our own route and removing the kernel provided
one.
Note that this adds a major change in that we no longer call
nm_ip4_config_commit() for assumed devices.
https://bugzilla.gnome.org/show_bug.cgi?id=723178
Signed-off-by: Thomas Haller <thaller@redhat.com>
When calling update_default_route(), NMDefaultRouteManager will look at the
source, and determine whether it has a default route or not. For example
for device sources, this means calling nm_device_get_ip4_default_route().
If the source indicates that it has no default route, the effect of
calling update_default_route() is the same as calling
remove_default_route() (hence, remove() can be replaced by update()).
If the source however still indicates a default route, the behavior
would be different. This case would be an undesired inconsistancy,
because source and NMDefaultRouteManager would disagree of whether
the source has a default route.
Source must always properly indicate whether it has a default route
or not, hence this situation does not arise.
Hence it is always better to call update().
Signed-off-by: Thomas Haller <thaller@redhat.com>
NetworkManager[31624]: <warn> VPN service 'openvpn': could not launch the VPN service. error: (8) Failed to execute child process "/usr/local/libexec/nm-openvpn-service" (No such file or directory).
**
NetworkManager:ERROR:nm-manager.c:3094:_activation_auth_done: assertion failed: (error)
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
The DRM now affects DNS too, since it determines the "best" IPv4
and IPv6 configs based on it's idea of the default route. The
Policy is also still updating DNS from a state-change handler for
VPN connections.
This led to a situation where the Policy would remove the VPN's
IP config from the DNS manager in vpn_connection_deactivated() and
call update_ip4_dns(), whereupon get_best_ip4_config() returned
the just-removed VPN IPv4 config as "best" because the VPN connection
hadn't yet told the DefaultRouteManager to remove it.
Which meant VPN nameservers stuck around in resolv.conf for a long
time after the VPN was disconnected.
Fixes: a39a3ae4cd
Extend NMDefaultRouteManager to track NMVpnConnection beside
NMDevice. That way, all default routes are managed by
NMDefaultRouteManager.
For VPN connections the manager also tracks connections that are
set never_default. That is useful because NMPolicy still uses VPNs
without default route to setup DNS. Hence, NMDefaultRouteManager
trackes those connections to have the relative priority of the
devices.
Interestingly, that means that for VPNs that are ipv4.never-default,
ipv4.route-metric still has an effect in determining relative priorities
for DNS configuration.
This commit only adds the parts to track the default route. NMPolicy
still sets the route as before.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Make use of the new setting nm_setting_ip_config_get_route_metric()
If set, this override the route metric determined based on the device
type.
Similarly for VPN also prefer the setting from the connection. Thereby change
the default priority (for VPN that have their own device) to NM_VPN_ROUTE_METRIC_DEFAULT
instead of NM_PLATFORM_ROUTE_METRIC_DEFAULT. The latter would be a very
low priority compared to the default metrics for devices.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before, we would always call unanimously nm_device_get_priority()
to get the default route metric for a device. Add new functions
nm_device_get_ip4_route_priority() and nm_device_get_ip6_route_priority()
and use them at the proper places.
Also add new function nm_vpn_connection_get_ip4_route_metric() and
nm_vpn_connection_get_ip6_route_metric().
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_device_get_priority() is used to select the "best" device
for the default route. The absolute values don't matter
at that point and the relative ordering is not changed by
this patch.
It is also directly used for route priority/metric. As we soon
allow the user to overwrite the setting, we want to get more
space between the individual device-types.
That way, a user could overwrite the default metric for a wifi
device to be 109 (making it lower then the default value 110), but
still less preferred then other non-wifi types.
Obviously, this patch is a visible change of behavior as now
routes get different metrics assigned.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Kernel, netlink an NMPlatformRoute treat route metrics as
uint32. Fix several places to use the exact type.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route
and NMIP6Route into NMIPRoute. The new types represent IP addresses as
strings, rather than in binary, and so are address-family agnostic.
