This bug was present since a long time, however libnl3-v3.2.23
(commit fdd1ba220dd7b780400e9d0652cde80e59f63572) changed the returned
family of bridge link objects, which breaks NetworkManager.
This resulted in error messages such as:
DBG<4> object.c:207 nl_object_get: New reference to object 0x19c34b0, total 2
DBG<5> route/link.c:895 link_keygen: link 0x19c34b0 key (dev 9 fam 7) keysz 8, hash 0x2b2
DBG<2> hashtable.c:127 nl_hash_table_add: Warning: Add to hashtable found duplicate...
DBG<4> object.c:221 nl_object_put: Returned object reference 0x19c34b0, 1 remaining
NetworkManager[17745]: <error> [1392114373.475432] [platform/nm-linux-platform.c:1328] event_notification(): netlink cache error: Object exists
Even before the change of libnl, I saw the following error lines
<debug> [...] [platform/nm-linux-platform.c:1216] event_notification(): netlink event (type 16) for link: virbr0 (4)
<error> [...] [platform/nm-linux-platform.c:1265] event_notification(): netlink cache error: Object exists
Hence, the caching mechanism for libnl objects already had a bug.
For rtnl link objects, the identifier consists of family and ifindex.
Since in upper layers, we don't easily know the family, we need a way to find
the objects inside the cache. We do this, by only caching links of family
AF_UNSPEC.
Objects that we receive via event_notification() are never cached. They are only used
to trigger refetching the kernel_object. Their family is irrelevant, we
only need to know, that something about this ifindex changed.
For objects retrieved via get_kernel_object(), we only get link objects of
family AF_UNSPEC or AF_BRIDGE. In any case, we reset (coerce) their family
before caching. This way, inside the link cache, there are only objects with
(coerced) family AF_UNSPEC. We loose the information, which family the
link had, however we don't need it anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=719905https://bugzilla.redhat.com/show_bug.cgi?id=1063290
Duplicates:
https://bugzilla.gnome.org/show_bug.cgi?id=724225https://bugzilla.redhat.com/show_bug.cgi?id=1063800
Signed-off-by: Thomas Haller <thaller@redhat.com>
The previous implementation called nl_object_get() and nl_object_put()
each time in link_get(). As nl_object_get() and nl_object_put()
causes debug logging in libnl, this clutters the output.
Signed-off-by: Thomas Haller <thaller@redhat.com>
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.
