Software devices don't have a UDI until udev finds them, and since we need
to know about the software devices before udev finds them the UDI will be
missing. Instead of requiring a UDI on NMDevice creation, update the
property from the NMPlatform link change signal when udev does find the
device.
Now that a UDI is no longer required for device creation, software devices
added by NM would be created in the platform_link_added_cb() signal
handler triggered by the various software device creation methods in
system_create_virtual_device() (eg nm_platform_bridge_add() etc). Then
the NMDevice created in system_create_virtual_device() would be a duplicate
and cause problems when it was added. Since system_create_virtual_device()
needs to do setup on some devices, suppress the device creation from the
platform link added handler in this function.
Much of this is a hack which should be cleaned up later.
The unref in finalize is not needed, because the hash table gets already freed
in dispose.
Note that setting available_connections to NULL in dispose is not really
needed, because (altough dispose might be called more than once) there
is a guarded by "priv->disposed = TRUE;". But leave it for clearity in
case somebody tries to access the pointer (which shouldn't happen).
Signed-off-by: Thomas Haller <thaller@redhat.com>
If a device is removed, then trying to reset its IPv6 state will cause
nm_utils_do_sysctl() to log a warning since the path no longer exists.
So don't try to do it in that case.
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.
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 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.
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.
