They look exactly like normal Ethernet interfaces, but they are managed
entirely by the Open vSwitch tools in software, so NM shouldn't (yet)
touch them. Treat them instead as generic devices that only get touched
through direct user requests.
platform/nm-linux-platform.c: In function 'delete_object':
platform/nm-linux-platform.c:102:13: error: 'cached_object' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (object && *object) {
^
platform/nm-linux-platform.c:1019:35: note: 'cached_object' was declared here
Except that it won't be, but I guess the gsystem auto* stuff is
confusing the compiler.
The platform still needs to know about them, becuase the ethernet interface
is what gets configured and used for IP. But the Manager doens't want to
create a full new NMDevice for them, because there's already a Modem
device that "owns" that WWAN interface. So keep WWAN devices visible
to the platform, but just make the manager ignore them when creating
NMDevices.
Also, many WWAN pseduo-ethernet drivers set NOARP becuase they really
are point-to-point and thus ARP is pointless, and in this case, they
won't have any arptype of ARPHRD_ETHER. So determining the NMLinkType
from udev must take that into account.
NM knows software devices it creates exist immediately, and it knows
it can use them immediately instead of waiting for udev to find them.
Ideally we'd wait for udev to find all devices, to allow tags and
other rules to run, but when creating software devices they must
currently be available for use immediately.
Bridges and bonds are required to be IFF_UP before they can be
activated (see their is_available() implementation). But during
activation code paths, specifically in nm_manager_activate_connection(),
the interface is created and immediately checked for availability
to activate (since the creation was a result of the user requesting
device activation). That availability check fails, because the
device is not visible outside NMPlatform (because it hasn't been
found by udev yet, because we haven't gotten back to the event
loop) and thus nm_platform_link_is_up() fails, failing the
availability check. Thus the device activation ends in error.
What should really happen is that device activation shouldn't
be synchronous; a new NMActiveConnection should be created for
any activation request, which can then wait until all the
resources it needs for activation are available (device found,
master devices created, etc). That's going to take more work
though.
Most places except the tests don't want the default route when asking
the platform for all routes, so make that simpler by just adding a
parameter for including the default route or not.
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
