to_string_link() logs link details and creates a new link to do this,
filling in the various filed in init_link(). init_link() attempts to
fill in the driver name, and might call ethtool to do that. Well,
ethtool API only accepts an interface name (which we don't have) and
not an ifindex (which we do have), and dies. Ensure that the ethtool
functions bail out instead of crashing if they don't get an interface
name.
Unfortunately, most callers of link_change() don't bother setting
ifindex or ifname on the link that ends up getting passed to
to_string_link(), because libnl doesn't require that when calling
rtnl_link_change(). Modify all callers to at least set the
ifindex so that to_string_link() has something useful to log.
NetworkManager[10651]: <info> (msh0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
NetworkManager[10651]: (platform/nm-linux-platform.c:684):link_extract_type: runtime check failed: (ifname != NULL)
NetworkManager[10651]: <error> [1398107504.807205] [platform/nm-linux-platform.c:1856] link_change(): Netlink error changing link 12: <UP> mtu 0 (1) driver 'usb8xxx' udi '/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.0/net/msh0': Message sequence number mismatch
at platform/nm-linux-platform.c:691
at platform/nm-linux-platform.c:1850
at devices/nm-device.c:5523
NM_DEVICE_STATE_REASON_NOW_MANAGED) at devices/nm-device.c:6662
at nm-manager.c:2115
Before platform raised 3 signals for each object type. Combine
them into one and add a new parameter @change_type to distinguish
between the change type.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Now we use init_link to print the rtnllink object, so be more
resilient to incompletly initilized objects and just set the
fields to NULL.
This fixes the (non harmful) warning:
<debug> [1397563880.690580] [platform/nm-linux-platform.c:1950] link_change_flags(): link: change 3: flags set 'up' (1)
init_link: assertion 'rtnl_link_get_name (rtnllink)' failed
file platform/nm-linux-platform.c: line 1021 (to_string_link): should not be reached
<error> [1397563880.690632] [platform/nm-linux-platform.c:1836] link_change(): Netlink error changing link (invalid link 0x7f88b5cf93c0): Unspecific failure
Signed-off-by: Thomas Haller <thaller@redhat.com>
Asserting against "/.." is wrong, because one could rename a link to
"..em1", which is a valid ifname but would crash NetworkManager.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Extended address flags are represented by the additional netlink
attribute IFA_FLAGS. Older kernels don't know this flag and refuse
the messages RTM_NEWADDR and RTMDEL_ADDR when it contains unknown
attributes. See net/core/rtnetlink.c, rtnetlink_rcv_msg(). This was
fixed by kernel commit 661d2967b3f1b34eeaa7e212e7b9bbe8ee072b59.
libnl was fixed in commit 5206c050504f8676a24854519b9c351470fb7cc6 only to
send the additional netlink attribute, when there are actually flags
that make this necessary.
This commit changes nm-platform to strip the flags to &= 0xFF, if we detect
that the kernel does not understand extended address flags.
https://bugzilla.redhat.com/show_bug.cgi?id=1063885
Signed-off-by: Thomas Haller <thaller@redhat.com>
When a VPN goes down, like at suspend, and the link has already
disappeared, the new platform logging code tries to print the
link information using a link object with only the ifindex filled
in. When adding/removing/changing links, internal code often fills
in just the ifindex (becuase that's all you need). Thus
to_string_link() will always fail if that operation fails.
at platform/nm-linux-platform.c:688
at platform/nm-linux-platform.c:1835
at vpn-manager/nm-vpn-connection.c:274
Work around that for now and live with the warnings until
we decide what to actually do about to_string_link().
When an interface gets renamed, we first receive a libnl update with
the changed interface name.
This results in the following chain of calls:
- event_notification()
- announce_object()
- link_init()
- link_extract_type()
- link_type_from_udev()
Then link_type_from_udev() looks up the name in the udev data (getting
the previous name, because we did not yet recieve the udev notification)
and passes the name to wifi_utils_is_wifi(), which eventually calls
nm_platform_link_get_ifindex() -- doing a lookup by the old name.
Fix this, by passing the ifname from libnl to link_type_from_udev().
Also, change hack_empty_master_iff_lower_up() because it is called
from event_notification(), at a moment when the link cache possibly
does not yet know the ifindex -- so that the call chain to
link_extract_type(), link_type_from_udev(), wifi_utils_is_wifi()
again might lead to lookup for something that does not yet exist.
Note, that in this case the name would not yet exist, because we
did not yet put the libnl object into the link cache.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Since vxlan is new-ish, and vxlan IPv6 support in particular has only
been in the kernel since 3.11, we include our own copy of the vxlan
netlink constants rather than depending on the installed headers.
The nla_policy struct declarations for GRE, etc, were originally
copied from the kernel sources, where they used tabs to align the "="
columns. Fix them to use spaces instead.
Also assert inside of sysctl_get() that we read the expected file
locations. Especially because now we might log the content of these
files.
Signed-off-by: Thomas Haller <thaller@redhat.com>
We don't thoroughly log the pointer values of our libnl objects,
so the logging in check_cache_items() is not usefull, it only
clutters the logfile.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Remove the "silent_on_error" flag from nm_platform_sysctl_get(), and
make both get() and set() log at debug level on ENOENT and error level
on all other errors, always.
Also ensure that we don't sometimes write "failed to set 'x' to 'y':
Success" when a partial write occurs.
Such a failure can happen easily, because we now request an initial dump
to get AF_INET6 addresses in order to check for extended ifa flags support.
This is not critical, so downgrade the error log.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Make sure NMPlatformGreProperties->path_mtu_discovery is always TRUE
or FALSE, even if the value from the kernel is "2" or "16" or
something. (This makes it consistent with what we do for other boolean
netlink properties.)
- refactor delete_object() by merging with delete_kernel_object()
- allow deletion of object that we cannot find in the cache
currently. The kernel might have such an address, even if we don't
have it currently cached. In this case, fall back to @obj.
Also try to work around an issue, that we cannot delete an IPv4 route without
knowing its scope.
- suppress logging error message for NLE_NOADDR, which is a common
failure when deleting an address. But at the same time, add some more
debug logging, for NLE_NOADDR and NLE_OBJ_NOTFOUND.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Adding IPv4 routes, with a non-zero host identifer fails with an
error message. Adding IPv6 addresses, does not return an error,
but it seems to have no effect.
Thus we have to make sure that the host part of routes
is always zero.
Signed-off-by: Thomas Haller <thaller@redhat.com>
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>
