The logging macros _LOGD(), etc. are specific to each
file as they format the message according to their context.
Still, they were cumbersome to define and their implementation
was repeated over and over (slightly different at times).
Move the declaration of these macros to "nm-logging.h".
The source file now only needs to define _NMLOG(), and either
_NMLOG_ENABLED() or _NMLOG_DOMAIN.
This reduces code duplication and encourages a common implementation
and usage of these macros.
(cherry picked from commit ad7cdfc766)
Don't clear NMDevice @master in nm_device_cleanup() if the device link
is still enslaved because this causes an inconsistent state in which
the slave in included in the @slaves field of master device but
@master of slave device is NULL.
In such state, if the master link gets deleted, NM receives a change
event for each slave and a deletion event for the master; the change
events should also remove slaves from @slaves of master device, but
since their @master field is NULL the removal can't be performed.
Later, when the master deletion event is received, @slaves is not empty
in dispose() of NMDevice and the following assertion is triggered:
dispose: runtime check failed: (priv->slaves == NULL)
https://bugzilla.redhat.com/show_bug.cgi?id=1243371
(cherry picked from commit b557f91a1b)
If linklocal6_start() finds that the device already has an IPv6
link-local address and returns NM_ACT_STAGE_RETURN_FINISH, we don't
need to fill @out_config with an empty configuration. A non-NULL
@out_config is required only for ret = NM_ACT_STAGE_RETURN_SUCCESS.
Fixes: 396dc2b3b4
(cherry picked from commit 54d10f0ec1)
During merge_and_apply(), we merge several NMIPxConfig into a new
@composite. For 'ignore-auto-routes' and 'ignore-auto-dns', we want to
prevent certain routes/dns-settings to be merged.
But it is wrong to reject settings from all partial configs.
For example, especially ext_ipx_config and vpn_ipx_config contain
routes that we still must merge and preserve.
This was recently changed by 79630c11e5
and previously by ab6548c621. But it was
wrong for a long time already.
Also note, that nm_ip4_config_merge() now also ignores NIS, WINS, and
dns-options.
https://bugzilla.gnome.org/show_bug.cgi?id=752546
Fixes: 79630c11e5
(cherry picked from commit 43e6f6a178)
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)
