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>
Add AddressData and RouteData properties to NMSettingIPConfig and
NMIP[46]Config. These are like the existing "addresses" and "routes"
properties, but using strings and containing additional attributes,
like NMIPAddress and NMIPRoute.
This only affects the D-Bus representations; there are no API changes
to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the
additional information is just added to the existing 'addresses' and
'routes' properties.
NMSettingIP4Config and NMSettingIP6Config now always generate both
old-style data ('addresses', 'address-labels', 'routes') and new-style
data ('address-data', 'gateway', 'route-data') when serializing to
D-Bus, for backward compatibility. When deserializing, they will fill
in the 'addresses' and 'routes' properties from the new-style data if
it is present (ignoring the old-style data), or from the old-style
data if the new-style isn't present.
The daemon-side NMIP4Config and NMIP6Config always emit changes for
both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The
libnm-side classes initially listen for changes on both properties,
but start ignoring the 'Addresses' and 'Routes' properties once they
know the daemon is also providing 'AddressData' and 'RouteData'.
The gateway is a global property of the IPv4/IPv6 configuration, not
an attribute of any particular address. So represent it as such in the
API; remove the gateway from NMIPAddress, and add it to
NMSettingIPConfig.
Behind the scenes, the gateway is still serialized along with the
first address in NMSettingIPConfig:addresses, and is deserialized from
that if the settings dictionary doesn't contain a 'gateway' key.
Adjust nmcli's interactive mode to prompt for IP addresses and gateway
separately. (Patch partly from Jirka Klimeš.)
NMSettingIP[46]Config let you associate a gateway with each address,
and the writable settings backends record that information. But it
never actually gets used: NMIP4Config and NMIP6Config only ever use
the first gateway, and completely ignore any others. (And in the
common usage of the term, an interface can only have one gateway
anyway.)
So, stop pretending that multiple gateways are meaningful; don't
serialize or deserialize gateways other than the first in the
'addresses' properties, and don't read or write multiple gateway
values either.
Now that NMSettingIP6Config inherits the dhcp-send-hostname property
from NMSettingIPConfig, fix things up so that it actually gets used.
(Note that this changes behavior: previously if ip6.dhcp-hostname was
unset, no hostname would be sent. Now, the system hostname will be
set. Also, ifcfg-rh does not currently support this property, so there
is no way to disable this...)
Split a base NMSettingIPConfig class out of NMSettingIP4Config and
NMSettingIP6Config, and update things accordingly.
Further simplifications of now-redundant IPv4-vs-IPv6 code are
possible, and should happen in the future.
Add key-value attributes to NMIPAddress and NMIPRoute, and use them to
store IPv4 address labels. Demote NMSettingIP4Config:address-labels to
a D-Bus-only property, and arrange for :addresses setter to read the
labels out of that property when creating the addresses.
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.
Missing initializers together with automatic cleanup seem to annoy GCC's
-Werror=maybe-uninitialized, breaking the --enable-more-warnings=error
builds.
We must also remove -Waggregate-return from m4/compiler-warnings.m4 because systemd
uses aggregate return (correctly) in a couple cases, and we cannot keep single-level
makefiles and override aggregate-return only for the systemd sub-library.
This client currently only supports DHCPv4 because the base systemd code
does not yet fully support DHCPv6.
The systemd code was modified to add "#if 0 /* NM_IGNORED */"
around lines that cause problems for compilation or code that is
not actually used in the library.
An adaptation layer (nm-sd-adapt) was added for glue between
systemd functions and NetworkManager, but changes to the actual
systemd code have been kept to a minimum.
The sd_event/sd_event_source functions of systemd have been
re-implemented on top of the GLib main loop.
client->secs wasn't getting set in the REBOOT state, causing
an assertion. REBOOT should work the same way as INIT, per
RFC 2131:
secs 2 Filled in by client, seconds elapsed since client
began address acquisition or renewal process.
REBOOT is necessary because many DHCP servers (especially on
home routers) do not hand back the same IP address when in
response to a DISCOVER packet, even if the same client ID is used.
The raw socket sd_event_source used for DHCP server solicitations
was simply dropped on the floor when creating the new UDP socket
after a lease has been acquired. Clean it up properly so we're
not still listening and responding to events on it.
Non-ethernet interface types use different client identifier formats,
plus when doing DHCPv4 and DHCPv6 on the same interface, the client
identifier should be related per RFC 4361. Thus let the caller
override the existing MAC-based client identifier if necessary.
