Things explode on i386 when marshalling a 32-bit value when a 64-bit one is
expected:
Program received signal SIGSEGV, Segmentation fault.
__memset_sse2 () at ../sysdeps/i386/i686/multiarch/memset-sse2.S:242
242 movdqu %xmm0, (%edx)
Missing separate debuginfos, use: debuginfo-install nss-mdns-0.10-15.fc21.i686
(gdb) bt
#0 0xffffffff in __memset_sse2 () at ../sysdeps/i386/i686/multiarch/memset-sse2.S:242
#1 0xffffffff in g_hash_table_remove_all_nodes (__len=<optimized out>, __ch=0, __dest=<optimized out>)
at /usr/include/bits/string3.h:84
#2 0xffffffff in g_hash_table_remove_all_nodes (hash_table=hash_table@entry=0x82ee250<error reading variable: Cannot access memory at address 0x8dbaacd6>, notify=notify@entry=1) at ghash.c:481
#3 0xffffffff in g_hash_table_unref (hash_table=0x82ee250<error reading variable: Cannot access memory at address 0x8dbaacd6>) at ghash.c:1042
#4 0xffffffff in _g_type_boxed_free (type=136861824, value=0x82ee250) at gtype.c:4262
#5 0xffffffff in boxed_proxy_value_free (value=0xbfffe8ec) at gboxed.c:209
#6 0xffffffff in g_value_unset (value=value@entry=0xbfffe8ec) at gvalue.c:272
#7 0xffffffff in g_signal_emit_valist (instance=instance@entry=0x82492b8, signal_id=signal_id@entry=125, detail=detail@entry=0, var_args=<optimized out>, var_args@entry=0xbfffea4c "\030\342.\bL#") at gsignal.c:3338
#8 0xffffffff in g_signal_emit (instance=0x82492b8, signal_id=125, detail=0) at gsignal.c:3365
#9 0x0809c05d in handle_event (proxy=0xb5d012e8 [DBusGProxy], options=0x82eb640 = {...}, user_data=0x82492b8)
at dhcp-manager/nm-dhcp-listener.c:146
#10 0xffffffff in g_cclosure_marshal_VOID__BOXED (closure=0x82bf270, return_value=0x0, n_param_values=2, param_values=0x82c60c0, invocation_hint=0xbfffec68, marshal_data=0x0) at gmarshal.c:1120
#11 0xffffffff in marshal_dbus_message_to_g_marshaller () at /lib/libdbus-glib-1.so.2
#15 0xffffffff in <emit signal received:org-freedesktop-nm_dhcp_client-Event on instance 0xb5d012e8 [DBusGProxy]> (instance=0xb5d012e8, signal_id=19, detail=915) at gsignal.c:3365
#12 0xffffffff in g_closure_invoke (closure=0x82bf270, return_value=return_value@entry=0x0, n_param_values=n_param_values@entry=3, param_values=param_values@entry=0xbfffecc0, invocation_hint=invocation_hint@entry=0xbfffec68) at gclosure.c:768
#13 0xffffffff in signal_emit_unlocked_R (node=node@entry=0x8263660, detail=detail@entry=915, instance=0xb5d012e8, emission_return=emission_return@entry=0x0, instance_and_params=0xbfffecc0) at gsignal.c:3553
#14 0xffffffff in g_signal_emit_valist (instance=instance@entry=0xb5d012e8, signal_id=signal_id@entry=19, detail=detail@entry=915, var_args=0xbfffee34 "\340\370.\b\004",
var_args@entry=0xbfffee2c "\340\370.\b\300\303/\b\340\370.\b\004") at gsignal.c:3309
#16 0xffffffff in dbus_g_proxy_manager_filter () at /lib/libdbus-glib-1.so.2
#17 0xffffffff in dbus_connection_dispatch () at /lib/libdbus-1.so.3
#18 0xffffffff in message_queue_dispatch () at /lib/libdbus-glib-1.so.2
#19 0xffffffff in g_main_context_dispatch (context=0x8246720) at gmain.c:3111
#20 0xffffffff in g_main_context_dispatch (context=context@entry=0x8246720) at gmain.c:3710
#21 0xffffffff in g_main_context_iterate (context=0x8246720, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#22 0xffffffff in g_main_loop_run (loop=0x8246798) at gmain.c:3975
#23 0x08070c09 in main (argc=1, argv=0xbffff2b4) at main.c:479
(gdb)
PIDs use native word width, a gint seems more suitable than gint32 or gint64.
https://bugzilla.gnome.org/show_bug.cgi?id=739861
When quitting, the Manager asks each device to spawn the interface helper,
which persists and manages dynamic address on the interface after NetworkManager
is gone. If the dynamic address cannot be maintaned, the helper quits and
the interface's address may be removed when their lifetime runs out.
To keep the helper as simple as possible, NetworkManager passes most of the
configuration on the command-line, including some properties of the device's
current state, which are necessary for the helper to maintain DHCP leases
or IPv6 SLAAC addresses.
Cloud setups often have a never-changing setup and since every cycle counts,
they don't really want a management process running in the background after
network setup is complete. Since it's likely a VM, it's not like links
are going to go up/down very often.
Add a new "configure-quit=true/false" config option which, when set to true,
will quit NetworkManager after startup and initial configuration is complete.
Really only used by systemd because it doesn't have as good lease
handling, but it's also necessary if we switch DHCP clients mid-stream
(which we'll be doing later) since the new DHCP client won't
have a lease file for the current IP address, and thus has nowhere
to pull the current IP address from to request the same address
from the DHCP server.
Make the type return GBytes since most in-tree users want that.
Allow the function to accept many more formats as valid hex, including
bytes delimited by ':' and a leading '0x'.
shvar.c has apparently never stripped trailing whitespace, but
obviously a shell doesn't care. Unfortunately NM does. Strip
trailing whitespace before unescaping, to preserve quoted
whitespace.
https://bugzilla.redhat.com/show_bug.cgi?id=1100336
This fixes an assertion during shutdown. NMManager:dispose()
calls remove_device(), which eventually hit the assertion
in nm_default_route_manager_ip4_get_best_device().
Remove the assertion, but also make sure that the function only
returns devices from the provided list. It is counter intuitive,
that the function might return devices that are not in the provided
list.
Signed-off-by: Thomas Haller <thaller@redhat.com>
We'll ever have WWAN devices with a NULL gateway because the IPv6 over
WWAN still uses router advertisements to get a prefix. Thus you'll
always have a gateway if the device has real IPv6 connectivity.
For the IPv4 case, we still allow default routes without gateway on
WWAN.
https://bugzilla.gnome.org/show_bug.cgi?id=735512
Signed-off-by: Thomas Haller <thaller@redhat.com>
Now that both VPN and devices are managed (and ordered) by
NMDefaultRouteManager, refactor get_best_config() to use the
priority accordingly.
Before, we would first iterate over all VPN connections and
returning the best one. Only if no suitable VPN connection
was found, a best device would be returned.
Modify get_best_config() to treat VPN and device the same and
return the best one based on the route metric.
With this change, get_best_config() gives consistent results
together with get_best_device(). Also, you can configure
that a device gets a higher priority then a VPN.
Signed-off-by: Thomas Haller <thaller@redhat.com>
get_best_device() has two different modes depending on the @fully_activated argument.
If @fully_activated, it only considers devices that are considered as active.
Otherwise, it returns the best activating device (if that device is expected
to be better then any of the already activated devices).
Before, the check whether an activated device is considered best device
also involved looking at the device state. This redundancy was harmful
because part of NMDefaultRouteManager considered a device as fully activated,
but get_best_device() might not return them.
Split get_best_device() in two parts. The one part _ipx_get_best_activating_device()
now checks for still activating devices. When inspecting devices with
an entry, those devices are weighted according to _ipx_get_best_device().
That means that both functions now give a consistent result.
Signed-off-by: Thomas Haller <thaller@redhat.com>
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>
NMDefaultRouteManager has a sorted list of routes. Change get_best_device()
to better consider that list when choosing a best device.
Always prefer the priority as reported from entry->effective_metric
if the device is registered to have a default route. Before for
!fully_activated, we choose the metric based on
nm_device_get_ipx_route_metric().
Add more checks in case of equal priority. For @fully_activated,
always prefer the device that is sorted by NMDefaultRouteManager.
For non @fully_activated, prefer the device with an entry.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Up to now, NMPolicy would iterate over all devices to find the "best"
device and assign the default route to that device.
A better approach is to add a default route to *all* devices that
are never-default=no. The relative priority is choosen according to
the route metrics.
If two devices receive the same metric, we want to prefer the device
that activates first. That way, the default route sticks to the same
device until a better device activates or the device deactivates.
Hence, the order of activation is imporant in this case (as it is
already now).
Also, if several devices have identical metrics, increment their
metrics so that every metric is unique.
This makes the routing deterministic according to what we choose as best
device.
A special case is assumed devices. In this case we cannot adjust the metric
in face of equal metrics.
Add a new singleton class NMDefaultRouteManager that has a list of all
devices and their default routes. The manager will order the devices by
their priority and configure the routes using platform.
Also update the metric for VPN connections. Later we will track VPN
routes also via NMDefaultRouteManager. For now, fix the VPN metric because
otherwise VPNs would always get metric 1024 (which is usually much larger then the
device metrics).
https://bugzilla.gnome.org/show_bug.cgi?id=735512
Signed-off-by: Thomas Haller <thaller@redhat.com>
get_best_ip4_config() and get_best_ip6_config() checked both for
never-default of the setting. This check was redundant, because
the never-default value was already merged into NMIPXConfig.
Signed-off-by: Thomas Haller <thaller@redhat.com>
In get_best_ip4_device() and get_best_ip6_device(), move
conditions to check for suitable connection first.
Makes the following patch more coherent.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When adding a default route fails, the most common
reason is that we don't have a direct route to the gateway.
In that case, NMPolicy tries to add a direct route to
the gateway and then retries adding the default route.
For VPN however, previously NMPolicy would not added a direct
route to the gateway via the VPN device. Instead it would add a
direct route to the external gateway via the parent interface.
That is wrong.
Indeed the external gateway must be reachable directly not via the
VPN interface itself. But for that the vpn connection already sets
a route via nm_device_set_vpn4_config().
Signed-off-by: Thomas Haller <thaller@redhat.com>
These lines are part of NM for a very long time.
I think they are wrong, because the default route is not
added to the NMIP4Config/NMIP6Config objects.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add a new enum NMPlatformGetRouteMode. This extends the existing
functions nm_platform_ip4_route_get_all() and nm_platform_ip6_route_get_all()
to return default routes only.
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>
As we use NMLinkType in NetworkManagerUtils.h, we cannot use
the utils header without nm-platform.h. That is clearly wrong.
Apparently NMLinkType has a wider use outside of platform (and
its name is not prefixed with 'platform' either).
Move the enum definition to nm-types.h.
Signed-off-by: Thomas Haller <thaller@redhat.com>
