According to documentation, nl_rtgen_request() returns 0 on success.
Due to a bug (fixed upstream) in older libnl versions, nl_rtgen_request()
returns the number of bytes sent, which caused logging although
succeeding.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The kernel adds a new capability to allow user space to manage
temporary IPv6 addresses. We need to detect this capability
to act differently, depending on whether NM has an older kernel
at hand.
This capability got introduced together when extending the
ifa_flags to 32 bit. So, we can check the netlink message,
whether we have such an nl attribute at hand.
Signed-off-by: Thomas Haller <thaller@redhat.com>
nl_socket_add_memberships expects a variadic list of int,
NULL is possibly defined as ((void *) 0) or 0L.
Signed-off-by: Thomas Haller <thaller@redhat.com>
It is common that the file exists, but cannot be read
(Operation not supported). So, silence any error when
reading the phys_port_id file.
Signed-off-by: Thomas Haller <thaller@redhat.com>
There seems to be the possibility of a race while reading tun
properties from sysctl. In this case, when being unable to
read the properties at construction of NMDeviceTun, we retry
shortly after.
- let tun_get_properties() not log any errors and it
does not stop on the first error but tries to read all
the values. Also, it initializes all fields of the output
structure with a default value (NULL).
- hard code kernel flag #ifndef in header files. Even if the
flag IFF_MULTI_QUEUE is not defined at compile time of NM,
it could still be supported by the kernel (eg. when booting
a newer kernel then the installed kernel headers). Simply
hard code the value, this value is not ever going to change
anyway.
https://bugzilla.redhat.com/show_bug.cgi?id=1034737
Signed-off-by: Thomas Haller <thaller@redhat.com>
In some cases, an error when reading the sysctl value can be expected.
In this case, we want to suppress the error message
Signed-off-by: Thomas Haller <thaller@redhat.com>
Tag addresses and routes with their source. We'll use this later to do
(or not do) operations based on where the item came from.
One thing to note is that when synchronizing items with the kernel, all
items are read as source=KERNEL even when they originally came from
NetworkManager, since the kernel has no way of providing this source
information. This requires the source 'priority', which
nm_ip*_config_add_address() and nm_ip*_config_add_route() must respect
to ensure that NM-owned routes don't have their source overwritten
when merging various IP configs in ip*_config_merge_and_apply().
Also of note is that memcmp() can no longer be used to compare
addresses/routes in nm-platform.c, but this had problems before
anyway with ifindex, so that workaround from nm_platform_ip4_route_sync()
can be removed.
https://bugzilla.gnome.org/show_bug.cgi?id=722843https://bugzilla.redhat.com/show_bug.cgi?id=1005416
When receiving an IPv4/IPv6 address from the kernel, platform set the
timestamp to an invalid value before. The address timestamp must be set
to *now*, because the lifetime and preferred arguments are counting from
now.
Signed-off-by: Thomas Haller <thaller@redhat.com>
For now, ignore them, as libnl does not support IPv6 PtP addresses
and returns an error. In the future perhaps we'll want to add a host
route for the peer instead of using the point-to-point address.
platform/nm-linux-platform.c: In function 'build_rtnl_addr':
platform/nm-linux-platform.c:116:15: error: 'bcaddr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
nl_addr_put (*object);
^
platform/nm-linux-platform.c:2264:32: note: 'bcaddr' was declared here
auto_nl_addr struct nl_addr *bcaddr;
^
In the migration to NMPlatform, support for ptp/peer addresses was
accidentally dropped. This broke OpenVPN configurations using 'p2p'
topology, which send a different peer address than the local address
for tunX, plus the server may also push routes that use the peer
address as the next hop. NetworkManager was unable to add these
routes, because the kernel had no idea how to talk to the peer,
because the peer's address was not assigned to any interface or
reachable over any routes.
Partly based on a patch from Dan Williams.
Use the new kernel physical_port_id interface property to recognize
when two devices are just virtual devices sharing the same physical
port, and refuse to bond/team multiple slaves on the same port.
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.
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.
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
