| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Fixup for NMSettingIPConfig changes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
#1083683)
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
If we can, read the existing client ID from the leasefile and preserve
it for later use.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This simplifies the manager and ensures that only the clients
that use D-Bus-based DHCP helpers need to care about them.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
We'll use this from more than one spot.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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'.
|
| |
|
|
| |
Necessary for GLib < 2.34
|
| |
|
|
|
| |
The AddressData and RouteData marshalling code were still using the
types from an earlier version of the branch. Fix that.
|
| |
|
|
|
| |
Fixes: f17699f4e3dacb9358a8503c8b15efe3cb852b48
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now NetworkManager will add a route for every device/VPN
that is not never-default. Multiple routes are prioritized
via the route metric.
https://bugzilla.gnome.org/show_bug.cgi?id=735512
https://bugzilla.redhat.com/show_bug.cgi?id=663730
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NMDefaultRouteManager
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>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
entries
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>
|
| | |
| |
| |
| | |
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
| | |
| |
| |
| |
| |
| | |
No functional change, only refactoring by moving and combining the code.
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>
|
| | |
| |
| |
| |
| |
| | |
No functional change, only refactoring by moving and combining the code.
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>
|
