core/pppd-plugin: wait to recover port settings before notifying death
pppd restores the previous settings for the serial port it uses right
before exiting. It is especially important to do so because otherwise
ModemManager is not able to recover the port as it can receive a hangup
event from the port due to CLOCAL not being restored. However, there is
currently a race condition that produces this issue. This is because
when PHASE_DEAD is notified, pppd still has not restored the port
settings - it does that a bit later, in the die() function.
This patch delays notifying PHASE_DEAD until when the exitnotify() hook
is called by pppd: when this happens the port settings have already been
restored.
There were previously efforts to fix this in commit fe090c34b724, so
PHASE_DEAD was used instead of PHASE_DISCONNECT to notify MM that the
port was disconnected, but that still early to ensure that the port
settings are restored.
The MM traces seen when the bug is triggered are:
ModemManager[2158]: <warn> (ttyACM1): could not re-acquire serial port lock: (5) Input/output error
ModemManager[2158]: <warn> Couldn't load Operator Code: 'Cannot run sequence: 'Could not open serial device ttyACM1: it has been forced close'
core: ignore IPv6 multicast in connection comparison
The default multicast route for IPv6 is set by default in some devices.
This makes comparisons between connections that should be the same to
fail, so they are not merged and unneeded connections appear in the
system. This commit make sure this does not happen. The route is
{ dest = "ff00::", prefix = 8 }. Fixes LP: #1811347.
core: ignore host-routes routes when matching generated connection
When we generate the connection in nm_device_generate_connection(), we
add all routes that have rt_source (roundtrip(NM_IP_CONFIG_SOURCE_USER)).
Especially since commit e470e1392242a088573c4fc317b7b5ffaca4df19, this
includes automatically added host-routes to the gateway, added by
ip4_config_merge_and_apply().
Later, during nm_utils_match_connection() this route most not prevent
matching. Either nm_device_generate_connection() should not add it, or
nm_utils_match_connection() should ignore it.
I think adjusting the matching is better, because ip-configs are used
for several things, including exposing routes on D-Bus. We don't want
to hide this route on D-Bus.
src: only compare network parts of routes in nm_utils_match_connection()
Kernel requires that routes have a host part of zero. For NetworkManager
configuration we allow non-zero host parts (but ignore them). Fix
route_compare() to ignore the host part.
This has only effect during assuming connections. That means, on
restart NM would fail to match a connection with static routes
if it has a non-zero host part. So, the impact is rather small.
(cherry picked from commit 034b7fb51c1d16a4002d2902c60aac05e946bb4f)
core: fix matching routes for assuming connections
If the connection candidate contains a static route
without route-metric, but overrides the default
route-metric, matching would have failed:
ipv4.route-metric: 200
ipv4.routes: { ip = 192.168.5.0/32 }
Then, we must not compare existing routes using the device's
metric, but must use the overwrite from the connection.
06511d9...
by
Beniamino Galvani <email address hidden>
device: take care of default route of DHCP generated-assumed connections
In general we don't touch the externally set default route on devices
that use a generated-assumed connection. When the IP method is AUTO
(or DHCP), this means that we are not able to restore the default
route after a temporary expiration of the lease which removes
addresses/routes from the device.
Change this, and let NM update the default route for generated-assumed
devices using dynamic addressing.
c8196c5...
by
Beniamino Galvani <email address hidden>
device: don't update applied connection for generated assumed devices
The applied connection must describe the configuration that was
initially activated on the device. Even if the IP configuration
changes, we shouldn't reset the applied connection for devices using a
generated-assumed connection, otherwise we would lose information on
the IP method we're trying on the device.
(cherry picked from commit c84fd50287086082a8037ccb112f99b1026edd17)
d1c241c...
by
System Enablement CI Bot <email address hidden>
Merged
into
~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager:network-manager/xenial/1.2.2
at
revision 342852a5adff3c59790f64b08fa509eaa3d2d3d2
