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.
The nm_platform_ip[46]_address_sync() functions no longer use
nm_platform_ip[46]_address_exists() to avoid adding already
existing addresses. That means nm_platform_ip[46]_address_add()
is now called for *all* commited addresses and the lifetimes
are thus always updated.
Because of that, nm_platform_ip[46]_address_add() had to be modified to
accept existing addresses and update their lifetimes when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=705102
When link goes !IFF_UP by internal or external action, we need to delete
related routes from the route cache. The same is done for both addresses
and routes upon link removal.
https://bugzilla.gnome.org/show_bug.cgi?id=704770
Current versions of libnl3 use nl_addr_get_len() instead of
nl_addr_get_prefixlen() to determine the default route. Therefore we're
employing a workaround that sets the address length to zero for default
routes.
Unfortunately this workaround causes nl_addr to have wrong address size,
which in turn requires another workaround in init_ip4_route() as well as
init_ip6_route() to cope with the inconsistency.
Even though this solution is very very ugly, we didn't find a better
one. Not calling rtnl_route_set_dst() didn't solve the problem. Thomas
Graf promised to fix the libnl problem upstream. When bumping dependency
to a version that does this correctly, the workarounds can be removed.
The whole point of having type_name separate from type was so that
unknown devices could still have known device types. But I wrote it
wrong and then didn't notice until explicitly vxlan support got
removed and vxlans started showing up as "unknown".
nm_platform_query_devices() was just looking in the link_cache,
completely ignoring udev, which means that the link list wasn't
filtered for things NM wants to ignore.
Add a "parent" field to NMPlatformLink, giving the parent device
ifindex for devices that have a parent.
Make nm_platform_link_get_all() sort the links before returning them,
so that masters appear after all of their slaves, and parent devices
appear before their children.
Remove the second call to nm_platform_query_devices() from NMManager
since it is now guaranteed that an NMDeviceVLAN's parent NMDevice will
have been created before the NMDeviceVLAN.
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.
This requires a very recent kernel to even compile, and the kernel
code is still rapidly changing (eg, adding IPv6 support). So take it
out for now, until it stabilizes.
This reverts commit 7f0f04d106.
Rather than having a bunch of udev-based tests, use
nm_platform_link_get_type() to categorize devices.
Incomplete, as NMPlatform still categorizes most hardware types as
"ETHERNET", so we still need udev-based tests for those.
https://bugzilla.gnome.org/show_bug.cgi?id=687254
Some devices aren't expected to support carrier detection, so there's
no reason to have NMDevice log about it. Move that message into
NMDeviceEthernet, where failure to support carrier-detect really is
worth mentioning.
Also, make NMDeviceEthernet use NMPlatform for carrier-detection
detection (and move the MII carrier-detect-support check from
NMDeviceEthernet into NMLinuxPlatform).
Finally, have NMDeviceGeneric actually check whether the device
supports carrier detect, rather than just always assuming it doesn't.
The bits in the result of ETHTOOL_GFEATURES are not in any defined
order; you need to use ETHTOOL_GSTRINGS to get the names associated
with each bit to find what each one does. Fix
NMPlatformLinux:link_supports_vlans() to do this.
https://bugzilla.gnome.org/show_bug.cgi?id=699649
On Linux, the gateway attribute is not a key attribute and therefore is
not necessary for functions that just need to identify a route. This may
be revisited when porting to other platforms but for now I want to keep
things simple.
In some cases, callers don't need to distinguish, eg,
ip4-address-added from ip6-address-added, but just need to know what
device the event occurred on. Make this simpler by including the
ifindex as a separate explicit argument, allowing callers to just
ignore the struct part.
Which it does whenever the 'bonding' module gets loaded no matter
what name the user wants to give the new bond interface.
Ported nm-system fix from commit 7cc95d8, using system() to avoid
dependency on NM libs.
Automatic test included. You have to run 'rmmod bonding' before testing
to ensure that the module is not already inserted. Second run without
rmmod always succeeds.
