The switch to combine IPv4 configs to arrive at the final config would
cause externally added addresses and routes to be removed from the
interface when a DHCP or LLv4 event came in, becasue the externally
added details weren't cached anywhere and thus would be dropped on the
IP changes.
When a VPN wanted to add some routes (like the host route for the
VPN gateway) it would add them itself and listen for parent device
events and re-add them if necessary. That's pretty fragile, plus
the platform blows away routes that aren't part of the IP config
that's getting applied.
So we might as well just have the VPN connection tell the parent
what the routes are, and have the parent device handle updating
the routing. The routes are through the parent device anyway,
and so are "owned" by the parent too.
Like IPv6, keep the DHCP/LLv4 config separate and combine it with the
NMSettingIP4Config to arrive at the final, combined IP4 config. This
brings the behavior in line with IPv6 code flow and will allow adding
the VPN routes config into the mix more easily.
It appears the kernel does not send notifications via netlink if the
default route is removed in some cases. This causes the platform
route cache to become stale, and thus when the default route is
reset by NM the platform thinks the route already exists, and does
not add it. But the route doesn't exist, becuase the kernel silently
removed it without telling anyone.
Fix that with a big hammer by flushing/refilling the route cache when
devices are deactivated (deletion of their addresses causes the default
route to be removed by the kernel) and when the default route is
updated by NM itself.
Pavel: if we find a more granular method, we should probably revert
this as the cache refill can be expensive.
Bluetooth device hardware addresses won't change during the lifetime
of the object (since that would mean a completely new device) and
they also won't have an ifindex because they aren't netdevices.
Various bits of the core periodically call nm_device_update_hw_address()
to update a device's hardware address, but this function expects that
any device with a hardware address also has an ifindex. Except that
Bluetooth devices don't because they aren't netdevices.
Modify the get_hw_address_length() function to return a boolean
indicating whether or not the address can ever change, and set that
for BT devices. nm_device_update_hw_address() then exits early if
there's no point in re-checking the hardware address, avoiding the
assertion.
https://bugzilla.gnome.org/show_bug.cgi?id=701744
The previous ignore-carrier rules did not work well with dynamic IP
(dhcp/slaac) connections. Change the rule so that only static IP
connections can be activated when carrier is not present (but both
static and dynamic connections will remain up when carrier is lost).
Callers of these functions now only care whether two IP configs are
different and not what specific property changed, so we can simplify
this code down to a simple comparison for equality, based on the hashing
that's already done for the DNS manager.
Note that this patch doesn't effectively change any code.
Functions moved from nm-system:
* nm_system_apply_ip?_config → nm_ip?_config_commit
* ip?_dest_in_same_subnet → nm_ip?_config_destination_is_direct
Functions moved from NetworkManagerUtils:
* nm_utils_merge_ip?_config → nm_ip?_config_merge_setting
Functions renamed (and moved down to form one group):
* nm_ip?_config_new_for_interface → nm_ip?_config_capture
(The rationale for the rename is that from the achitectural point of
view it doesn't matter whether the function creates a new object or
updates an existing one. After the rename, it's obvious that
nm_ip?_config_capture() and nm_ip?_config_commit() are counterparts of
each other.)
0652d9c596 changed IP states like this:
| old behaviour | new behaviour
---------------------------------------------------------
success | IP_DONE && config is not NULL | IP_DONE
failure | IP_DONE && config is NULL | IP_FAIL
But some failure paths was not updated.
nm_platform_*_sync() functions check the cached kernel configuration
items (addresses, routes) before adding addresses to the kernel.
Therefore we don't need to be so careful about pushing NetworkManager
configuration to the kernel.
This patch helps to avoid having to compare nm_ip[46]_config objects,
which should only be created when a configuration change is being
performed.
in nm_device_start_ip_check(), because it is called from the state handler
(nm_device_state_changed()).
Errors:
(devices/nm-device.c:5585):nm_device_state_changed: runtime check failed: (priv->in_state_changed == FALSE)
<info> (eth0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
The 'assume' parameter was misused for stuff that has nothing to do with
connection assumption. The 'commit' argument with reversed logic is much
clearer.
We can't clear the ip_iface until after all the routes and addresses
are updated and flushed, because the addresses and routes are
identified by the ip_iface, and if we clear the ip_iface, we don't
know which things to flush anymore.
Example: 'hso' modems have an 'iface' of 'ttyHS4' (a serial port) and
an ip_iface of 'hso0' (an ethernet port). If we clear the ip_iface too
soon, then ip_iface/ip_ifindex is invalid and thus NM has no idea what
to remove, and the default route pointing to 'hso0' sticks around.
This could also happen with other devices where the ip_iface is
different than the iface, like modems, ADSL/ATM devices, etc.
Using the new gateway-ping-timeout property, send pings to the first
gateway address until it replies or the timeout is reached, to deal
with dumb hardware that indicates carrier on but doesn't actually
pass traffic.
https://bugzilla.gnome.org/show_bug.cgi?id=702515
Just ignore this, since it happens in the current code and is
harmless. While we're here, improve the warning in the case where it
does occur to say whiich state we're overwriting. This should help
debug any future cases.
Due to the hardware address changes in 77dda53b (danw/hwlen) creating
a new Bluetooth device was crashing. The changes there assumed that the
NMDeviceBt's hardware address should only be valid when we were connected
to the device, but that's not quite true. Since we already know the remote
device's Bluetooth hardware address, we already know the hardware address
for the NMDeviceBt as well.
The function only checked whether wimax was enabled (rfkill/user pref)
and whether wimaxd was running. Only nm-device.c calls this function
for WiMAX devices, and the only two uses of it were during activation
(which is already covered by nm-device-wimax.c's is_available() function)
and when the device enters the UNAVAILABLE state, where it is used
to check for missing firmware, which is implemented by the parent
class, not WiMAX.
These turn out to be pretty useless, since their functions are already
covered by each device's state-changed handler or can be done in other
places like deactivate().
https://bugzilla.gnome.org/show_bug.cgi?id=702190
For device types that don't override it, make
nm_device_get_hw_addr_len() use NMPlatform to find out the actual
hardware address length, rather than just defaulting to ETH_ALEN.
Fixes warnings in the logs when using tun or gre devices.
nm_device_bt_new() was trying to set NM_DEVICE_MANAGED, but that's
been read-only now for a while. Fortunately, it was already trying to
set it to FALSE, which is the default, so we can just remove that
line.
https://bugzilla.gnome.org/show_bug.cgi?id=701715
NM is supposed to ignore carrier and slave states for manual/static
connections when bringing up bonds and bridges, on the theory that
since static configuration does not require connectivity, there's
no need to wait for that connectivity to happen. This wasn't
happening during the IP configuration phase, but was happening
before getting to the IP config phase where the device waits
for slaves before starting IP configuration if the method
requires connectivity.
'NM_DEVICE_IP_IFACE' has never been a writable property, just skip it and
explicitly call 'nm_device_set_ip_iface()' when the modem is managed by the old
ModemManager.
https://bugzilla.gnome.org/show_bug.cgi?id=701712
Rather than passing UDI, ifname, and driver name to the device
constructors as separate arguments, just pass the NMPlatformLink
instead and let it parse them out.
Virtual types still take UDI and ifname separately, since we create
fake NMDevices for them for autoactivating connections. That's weird
in other ways too though, so perhaps this should be revisted.
Merge the net-subsystem-monitoring functionality of NMUdevManager into
NMLinuxPlatform (and kill NMUdevManager). NMLinuxPlatform now only
emits link-added signals after udev processes the device, and uses
udev attributes to further identify the device. NMManager now
identifies devices solely based on the NMLinkType provided by the
platform.
