When doing a lookup for an libnl route, the cache comparison function
for routes takes into account 'family', 'tos', 'table', 'dst', and 'prio'.
In NetworkManager we don't use all of these properties for a route, so
at several places when doing a cache lookup we don't have all identifying
properties. Usually we only have 'family' and 'dst' ('table' is
implicit 0, because NM does currently not care about any other tables).
The problem is that NM sees routes with different 'tos', 'prio', but it
cannot look them up in the cache. Add a hack to search the cache
fuzzy.
This is similar to the hack for link, where the identifying properties
are 'family' and 'ifindex', but we only have 'ifindex' at hand. However,
contrary to this hack, we coerce the 'family' to AF_UNSPEC for every link cache
operation. This is not viable in this case, because we internally need
the 'tos' field.
We need the 'tos' field because when deleting an IPv4 route, the 'tos' field must
match. See fib_table_delete(). This was already partially fixed by commit
f0daf90298, but before the lookup to the
cached object would fail for any non-zero 'tos'.
Signed-off-by: Thomas Haller <thaller@redhat.com>
check_cache_items() iterated over all items and called refresh_object().
But refresh_object() might remove the current object from the cache, so
this would break the iteration.
Instead check the items in two steps. First find all the objects we care
about and build a list of them. Then check them.
Signed-off-by: Thomas Haller <thaller@redhat.com>
By passing INADDR_ANY as a gconstpointer, we actually always passed NULL
as gateway. Maybe this was not intended, but it seems correct now
and is proven to work. So this fixe has no behavioral change.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When deleting an IPv4 route, several fields must match (or be left
unspecified/zero). See fib_table_delete().
Previously, NM would look into the cache and use that object for
deletion. This was changed recently, thereby breaking the deletion
of routes by not specifying all properties as needed.
Fixes regression introduced by commit 019bf7512d.
Related: https://bugzilla.gnome.org/show_bug.cgi?id=726273
Signed-off-by: Thomas Haller <thaller@redhat.com>
Previously, we always lookup the cache for libnl objects and used those for
delete_object(). This was necessary, because libnl guesses and overwrites
the IPv4 route scope.
Newer libnl no longer overwrites the scope if set explicitly to RT_SCOPE_NOWHERE.
So, this workaround is no longer needed. Indeed there might be cases, where it is
harmful, because we might guess the wrong scope.
This was fixed in libnl3 in commits
85ec9c7ad8015c4ee59bhttps://bugzilla.gnome.org/show_bug.cgi?id=726273
Signed-off-by: Thomas Haller <thaller@redhat.com>
The libnl function nl_has_capability() was only added recently, so don't depend on it
at compile time. Instead use dlopen to load the function if the libnl library contains it.
Signed-off-by: Thomas Haller <thaller@redhat.com>
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>
