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.
(cherry picked from commit f7a8962dd4)
The MTU of 0 means default, not zero-length packets:
<warn> (wlp3s0): Lowering IPv6 MTU (1472) to match device MTU (0)
<warn> (wlp3s0): IPv6 MTU (0) smaller than 1280, adjusting
<warn> (wlp3s0): Raising device MTU (0) to match IPv6 MTU (1280)
<error> [1437068831.306733] [platform/nm-linux-platform.c:2440] sysctl_set(): platform-linux: sysctl: failed to set '/proc/sys/net/ipv6/conf/wlp3s0/mtu' to '1472': (22) Invalid argument
Reported-by: Jan Alexander Steffens <jan.steffens@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=752508
(cherry picked from commit a92d8b0c67)
Try to set the MTU of the parent Ethernet interface to match the
requested PPP MTU and MRU. This allows the negotiation of a PPP MTU
and MRU greater than 1492.
(cherry picked from commit 1d3eff45d2)
Commit d51975e changed, that we treat assumed and non-assumed
connections the same with respect to the default route. This is
certainly wrong, if we have an nm-generated-assumed connection
at hand. In this case, NM just generated a connection based on what
was configured on the system. Looking at that result and re-enforcing
the default-route is wrong.
We want to manage the default-route for assumed, persistent connections.
If the connection was assumed and generated, we do not.
This commit reverts d51975ed for nm-generated-assumed connection and
restores the previous behavior.
https://bugzilla.redhat.com/show_bug.cgi?id=1244483
Fixes: d51975ed92
(cherry picked from commit bebeff69e8)
Rename "default_route.v4_configure_first_time" to "v4_commit_first_time".
For one, the name "commit" matches better to the @commit variable in ip4_config_merge_and_apply()
and ip6_config_merge_and_apply(). Then, we don't need this information
only for default-routes, so move the variable out of the @default_route
struct.
(cherry picked from commit ad03cdbc73)
The metered property of a NMDevice that reaches the activated state is
copied from the active connection and if its value is 'unknown' some
heuristics are used to guess the actual value.
When the connection is torn down the metered property is reset to
'unknown'.
(cherry picked from commit a86255a043)
This makes wifi preferred to wwan (the modem and bluetooth device types
to be specific) by default, so that users that care about being
connected at all times can keep both enabled with auto-connect. As wifi
is usually unmetered and often faster than wwan, it makes sense to
prefer it. This is also how pretty much every smart-phone in the world
behaves, so it aligns better with user expectations too.
https://bugzilla.gnome.org/show_bug.cgi?id=744754
(cherry picked from commit 3efb6740fc)
In most cases, when syncing routes, we should only remove routes
that were configured by us previously. Otherwise, there is a race
that we can remove routes added externally.
Now, when applying IP configuration for a device, only do a full-sync
at the first time when we activate the device. Later on, only remove
routes that were added by us.
(cherry picked from commit 8b015826e6)
We currently don't manage a veth inside a container despite we should because
it's an externally configured software interface and thus waits for IFF_UP.
Given veths are prevented from being managed outside of a container by an udev
rule anyway it's safe to lift the external IFF_UP requirement for them.
(cherry picked from commit bcc79cc0eb)
priv->iface could change in device_link_changed() which reacts on platform link
changes caused by nm_platform_link_set_user_ipv6ll_enabled(). (The variable could
change between obtaining and using its value, because emitting a glib signal runs
callbacks synchronously).
Actually, the problem is already fixed by commit 04caae735f.
But still this is better.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1224366
(cherry picked from commit bb1692707f)
When adding an IPv4 address, kernel will also add a device-route.
We don't want that route because it has the wrong metric. Instead,
we add our own route (with a different metric) and remove the
kernel-added one.
This could be avoided if kernel would support an IPv4 address flag
IFA_F_NOPREFIXROUTE like it does for IPv6 (see related bug rh#1221311).
One important thing is, that we want don't want to manage the
device-route on assumed devices. Note that this is correct behavior
if "assumed" means "do-not-touch".
If "assumed" means "seamlessly-takeover", then this is wrong.
Imagine we get a new DHCP address. In this case, we would not manage
the device-route on the assumed device. This cannot be fixed without
splitting unmanaged/assumed with related bug bgo 746440.
This is no regression as we would also not manage device-routes
for assumed devices previously.
We also don't want to remove the device-route if the user added
it externally. Note that here we behave wrongly too, because we
don't record externally added kernel routes in update_ip_config().
This still needs fixing.
Let IPv4 device-routes also be managed by NMRouteManager. NMRouteManager
has a list of all routes and can properly add, remove, and restore
the device route as needed.
One problem is, that the device-route does not get added immediately
with the address. It only appears some time later. This is solved
by NMRouteManager watching platform and if a matchin device-route shows up
within a short time after configuring addresses, remove it.
If the route appears after the short timeout, assume they were added for
other reasons (e.g. by the user) and don't remove them.
https://bugzilla.gnome.org/show_bug.cgi?id=751264https://bugzilla.redhat.com/show_bug.cgi?id=1211287
(cherry picked from commit 5f54a323d1)
When ping is launched to check the connectivity to the gateway it may
return earlier than the given timeout in case of error. When this
happens we need to respawn it until the timeout is reached.
While at it, increase maximum timeout value to 600 seconds.
https://bugzilla.redhat.com/show_bug.cgi?id=1128581
(cherry picked from commit e86f8354a7)
When the platform link gets removed outside of NetworkManager, we would
unmanage the device first. By checking the device state reason
NM_DEVICE_STATE_REASON_REMOVED, we would then not deconfigure the
interface, as it is already gone.
This was not correct because we must at least stop the dhcp client.
Otherwise the dhclient process keeps running. That meant, if the device
reappeared later, we would start dhclient again. Then we would find the
PID of the still running instance in the pidfile and kill it only than.
Fix it by replacing the 'deconfigure' boolean by a tri-state
'cleanup_type'.
(cherry picked from commit 3b21738d9c)
Since commit ab6548c621 ("device: better accept external IP
changes"), ipX_config_merge_and_apply() applies the configuration
static settings to an intermediate, initially empty configuration
(priv->con_ipX_config) instead of the composite configuration, and
thus the handling of ignore-auto-routes and ignore-auto-dns options
done in nm_ipX_config_merge_setting() has no effect.
Fix this by clearing the routes and the DNS information when needed
before merging static settings to the composite configuration.
Fixes: ab6548c621
(cherry picked from commit 79630c11e5)
Without that we can remove addresses from con-ip6-config due to external
changes *before* it is applied and thus manual IPv6 addresses are not applied
together with ipv6.method=auto.
Testcase:
$ nmcli con add type ether con-name AAA ifname eth0 autoconnect no
$ nmcli con mod AAA ipv4.addresses 1.1.1.1/24 ipv6.addresses 99::99/64
$ nmcli con up AAA
Fixes:Beaker:NetworkManager_Test37_run_once_new_connection
Fixes:Beaker:NetworkManager_Test84_ipv6_addresses_no_when_static_switch_asked
https://bugzilla.gnome.org/show_bug.cgi?id=751430
(cherry picked from commit 0a00eb67dd)
The merge of lr/udev-unmanaged-fd731014 made all devices wait until
udev found them, but that makes these three device types fail activate
when created by NM itself.
Since their availability depended on IFF_UP, they could not be
activated (eg, 'nmcli con up team0') until they were IFF_UP. But
when they are created by NM, although NM knows the ifindex the
platform ignores the interface until udev finds it. Thus immediately
after creating the interface in _internal_activate_device() it
won't be known to the platform, so the nm_device_is_available()
check that controls whether the device moves to DISCONNECTED
will fail. This prevents any activation and emits the message:
"Connection 'foo' is not available on the device %s at this time."
because the device is still in the UNAVAILABLE state.
danw asked why we care about IFF_UP for these devices, and I can't
remember why, and I don't think it makes sense to require now.
https://bugzilla.gnome.org/show_bug.cgi?id=746918
(cherry picked from commit 568a8d1da9)
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.
(cherry picked from commit 874e4a7595)
Previously for assumed connections we would never configure a default route.
That has serious problems for example in the following two scenarios:
- the default-route might have a limited lifetime from a previous
SLAAC/accept_ra setting. In this case, once we assume the connection
we must also ensure that we extend the lifetime of the default
route.
- the gateway could be received via DHCP/RA and it might change.
If we ignore default-routes for assumed connection we miss that
change.
The problem is that the notion of "assumed connection" wrongly combines
two conflicting goals (related bug bgo#746440):
a) have an external device that is entirely unmanged by NM.
b) do a seamless takeover of a previously managed connection at start,
but still fully manage.
This patch changes the handling of default-routes towards meaning b).
https://bugzilla.redhat.com/show_bug.cgi?id=1224291
(cherry picked from commit d51975ed92)
Since da708059da, we would pickup the
default-route as configured externally, except at those moments when
NM re-applys the IP configuration of the interface, such as during a
DHCP lease.
That allows the user to add/remove the default-route externally (iproute).
But still, at random times (DHCP lease), we will revert those external
changes.
Extend this, that if the connection is explicitly configured as
'never-default=yes', that it tells NM not to interfere with externally
added default-routes on this device. That means, NM will only remove
any preexisting default-routes when configuring the device a first
time.
On any later attempts, NM will assume whatever is configured there.
That makes sense because the user indicated not wanting NM to
manage a default-route on that device, so if something externally
added a default-route, assume that is what the user wants.
This only affects non-assumed connections, with 'never-default=yes'.
https://bugzilla.redhat.com/show_bug.cgi?id=1205405
(cherry picked from commit 98e50e358b)
When a connection had static IP addresses, an early event
from plaform would clear them from priv->con_ip4_config.
Fix that, by don't initializing priv->con_ip4_config
before we commit the first time.
https://bugzilla.gnome.org/show_bug.cgi?id=749052
Fixes: 557667df12
(cherry picked from commit 843205521f)
It would subtract the configuration from device confguration that's not yet
applied. This a the race where the loose the address while activating a
connection that has both IPv6 and IPv4 configuration.
Fixes: 557667df12https://bugzilla.gnome.org/show_bug.cgi?id=746066
(cherry picked from commit 2e99ddb7a7)
Even more eagerly pickup external default routes from the device.
For assumed devices we already picked up the default route.
(a) For assumed devices we already did not enforce the default route at all.
Instead it was always picked up by from the actualy system
configuration. Note that this is the case for assumed-generated
connections and for assuming existing connections.
That means that when NM assumes a connection at startup, it will never
actively manage the default route on that interface. It will only react
on what is present.
(b) For managed devices that have by configuration no default route, still pick up
the default route. That means, that even a device that is managed and
never-default=yes, can have the default route -- if configured externally.
(c) Only during a commit phase (i.e. when we have new configuraiton to be
applied), we enforce the default route or its absence.
(d) During any IP change event from platform, we again pickup whatever
is present. That means if you remove the default route from a managed
interface, NM will not re-add it until anything triggers (c).
This also means, that during the commit phase, we add default routes as
'synced' to the default-route-manager, but the following event from platform,
will change the route entry immediately to 'non-synced'. That is
expected and correct.
(cherry picked from commit da708059da)
When receiving IP changes via platform event, remove all missing
addresses and routes from our internal configurations (such as
wwan, vpn, dhcp).
The effect is that on the next commit, those addresses and routes will
not be re-added as they were explicitly removed by the user.
However on a new DHCP lease or similar events, the addresses will
be added anew.
Another important improvement is that the NMIPxConfig of the active
device reflects when addresses or routes get removed externally. Before
we would continue to expose those entires although they were not
actually configured on the device.
https://bugzilla.gnome.org/show_bug.cgi?id=740443
(cherry picked from commit 557667df12)
In the IPv4 case, we check whether we have a direct route to the gateway
also by looking at the configured addresses/subnets. That is correct,
because every IPv4 address also implies a subnet route.
For IPv6, we explicitly add all subnet routes manually (noprefixroute),
hence, we have a direct route exactly if we have it in our list.
Regardless of the configured IPv6 prefixes.
(cherry picked from commit 2c06449085)
Change nm_platform_link_get() to return the cached NMPlatformLink
instance. Now what all our implementations (fake and linux) have such a
cache internal object, let's just expose it directly.
Note that the lifetime of the exposed link object is possibly quite
short. A caller must copy the returned value if he intends to preserve
it for later.
Also add nm_platform_link_get_by_ifname() and modify nm_platform_link_get_by_address()
to return the instance.
Certain functions, such as nm_platform_link_get_name(),
nm_platform_link_get_ifindex(), etc. are solely implemented based
on looking at the returned NMPlatformLink object. No longer implement
them as virtual functions but instead implement them in the base class
(nm-platform.c).
This removes code and eliminates the redundancy of the exposed
NMPlatformLink instance and the nm_platform_link_get_*() accessors.
Thereby also fix a bug in NMFakePlatform that tracked the link address
in a separate "address" field, instead of using "link.addr". That was
a case where the redundancy actually led to a bug in fake platform.
Also remove some stub implementations in NMFakePlatform that just
bail out. Instead allow for a missing virtual functions and perform
the "default" action in the accessor.
An example for that is nm_platform_link_get_permanent_address().
(cherry picked from commit e8e455817b)
When inside a state-change, we set for example the device up.
This triggers a link-changed event, which then causes further
state-changes of the devices.
A state-change in process of a device is not reentrant, so we must
delay the handling of the link-changed event.
(cherry picked from commit 04caae735f)
