The internal VLAN flags were translated into the kernel VLAN flags but
finally the internal ones were passed to the kernel instead.
Reported-by: Julien Nabet <serval2412@yahoo.fr>
If the WiMAX plugin isn't installed, or the WiMAX device isn't
recognized, NetworkManager shouldn't treat the interface as
regular ethernet since the device requires specific setup to
be ready for IP configuration, which of course NetworkManager
can't do because the WiMAX plugin isn't loaded. Ignore them
instead.
Actually, this case should no longer happen, but just to be sure:
when a udev remove event without ifindex comes, get the ifindex from
the cache and announce the device removal.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before NMPlatform landed, the old NMManager code looked at either
DEVTYPE=wlan or asked the internal wifi utilities whether the
device was WiFi or not. This got lost when moving to NMPlatform.
It turns out that only mac80211-based drivers set the DEVTYPE=wlan
flag in sysfs, while older WEXT, out-of-tree, and staging drivers
often do not (though they should).
To avoid breaking recognition of these crappy drivers that used
to work, re-add the wifi utils checks.
New functions to compare two instances of NMPlatformIP4Address, NMPlatformIP6Address,
NMPlatformIP4Route, NMPlatformIP6Route, respectively.
These functions return -1, 0 or 1 as result of the comparison. This is similar to
strcmp with the additional restriction, that only one of these 3 values will be
returned.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Fix infiniband_partition_add() to put the newly-created device into
the link_cache before returning. Fix link_is_software() to recognize
partition devices as software, so that link_get() is willing to return
them even before we get the udev info.
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.
Add *_to_string functions for address (ip4 and ip6) and
route (ip4 and ip6). Also refactor the previously existing
nm_platform_ip4_route_to_string function.
The to_string function returns a pointer to an internal
buffer. Also update log_* functions to make use of the new
to_string functions.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
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_platform_query_devices() wasn't including the new "reason" argument
in its link-added emissions. (This didn't cause any problems since
NMManager doesn't look at that argument anyway, but it's still
obviously wrong.)
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.
This is the same we already did for nm-platform addresses in commit
68c3e1153c. It will help to avoid various
issues and is also a step towards support for route lifetimes.
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
Addresses in the platform cache will have timestamp/lifetime/preferred set,
but addresses to be added or removed (like new IP config from DHCP renewal
or new RAs) won't have these set, since they only get set when the address
is actually added to the kernel. So when syncing addresses, we can't look
at any of these items or nothing matches, and all existing addresses get
removed.
https://bugzilla.gnome.org/show_bug.cgi?id=705102
