Cache the scope as part of the NMPlatformIP4Route and
no longer read it from libnl object when needed. Later
there will be no more libnl objects around, and we need
to scope when deleting an IPv4 route.
Ethernet, WiFi, and VLAN used the same implementation for initial address.
Ethernet and WiFi used the same implementation (and duplicated code) for
permanent MAC address, plus they both used ethtool in what should be
generic code, which is better done in the platform.
link_extract_type() would return the NMLinkType and a
@type_name string. If the type was unknown, this string
was rtnl_link_get_type() (IFLA_INFO_KIND).
Split up this behavior and treat those values independently.
link_extract_type() now only detects the NMLinkType. Most users
don't care about unknown types and can just use nm_link_type_to_string()
to get a string represenation.
Only nm_platform_link_get_type_name() (and NMDeviceGeneric:type_description)
cared about a more descriptive type. For that, modify link_get_type_name()
to return nm_link_type_to_string() if NMLinkType could be detected.
As fallback, return rtnl_link_get_type().
Also, rename the field NMPlatformLink:link_type to "kind". For now this
field is mostly unused. It will be used later when refactoring platform
caching.
We already have nm_*_platform_setup() that gets specified
via -DSETUP. This SETUP() hook gives us all the flexiblity
we need to customize our singleton, so just do any required
setup there.
Also, it would be easier to add an alternative (hypotetical)
nm_fake_platform_setup_custom() to customize the singleton then to
parametrize the NMPlatform:setup() implementation. So this virtual
function is less flexible and redundant.
We have two hooks to modify setup of the platform singleton:
nm_linux_platform_setup() and the virtual setup() function.
On the other hand, nm_platform_setup() limits us by accepting
only a GType, instead of a prepeared platform instance.
Make the nm_platform_setup() method more flexible, so that we can
later drop the setup() hook.
Some out of tree drivers add Ethernet devices that are supposed to be managed
by other their tooling, e.g. VirtualBox or VMWare.
Rather than hardcoding their drivers (at least VirtualBox doesn't even set a
"driver" property in sysfs) or hardcoding a logic that identifies such devices
let's just add a possibility to blacklist them in udev. This makes it possible
for whoever who ships such a driver to ship rules that prevent NetworkManager
from managing the device itself.
Furthermore it makes it possible for the user with special needs leverage the
flexibility of udev rules to override the defaults. In the end the user can
decide to let NetworkManager manage default-unmanaged interfaces such as VEth
or turn on default-unmanaged for devices on a particular bus.
An udev rule for VirtualBox would look like this:
SUBSYSTEM=="net", ENV{INTERFACE}=="vboxnet[0-9]*", ENV{NM_UNMANAGED}="1"
There's no udev running in containers, it only starts if /sys is writable. If a
hardware device is added to the container's namespace NM would not announce it.
This also removes the software link special case -- the software links will now
wait for udev initialization (in case udev is there) as well. There's no reason
to treat them differently anymore. This makes it possible to use udev properties
of the software links.
https://bugzilla.gnome.org/show_bug.cgi?id=740526
Since f32075d2fc, we remove the kernel
added IPv4 device route, and re-add it with appropriate metric.
This could potentially replace existing, conflicting routes. Be more
careful and only take any action when we don't have a conflicting
route and when we add the address for the first time.
The motivation for this was libreswan which might install a VPN route
for a subnet that we also have configured on an interface. But the route
conflict could happen easily for other reasons, for example if you
configure a conflicting route manually.
Don't replace the device route if we have any indication that
a conflict could arise.
https://bugzilla.gnome.org/show_bug.cgi?id=723178
config.h should be included from every .c file, and it should be
included before any other include. Fix that.
(As a side effect of how I did this, this also changes us to
consistently use "config.h" rather than <config.h>. To the extent that
it matters [which is not much], quotes are more correct anyway, since
we're talking about a file in our own build tree, not a system
include.)
Add a new enum NMPlatformGetRouteMode. This extends the existing
functions nm_platform_ip4_route_get_all() and nm_platform_ip6_route_get_all()
to return default routes only.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Kernel, netlink an NMPlatformRoute treat route metrics as
uint32. Fix several places to use the exact type.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Deleting an IPv4 address using libnl requires the proper peer address.
Pass the address of the peer on to nm_platform_ip4_address_delete().
Signed-off-by: Thomas Haller <thaller@redhat.com>
Change all DBUS_TYPE_G_UCHAR_ARRAY properties to G_TYPE_BYTES, and
update corresponding APIs. Notably, this means they are now refcounted
rather than being copied.
Update the rest of NM for the changes. The daemon still converts SSIDs
to GByteArrays internally, because changing it to use GBytes has lots
of trickle-down effects. It can possibly be changed later.
Lots of old code used struct ether_addr to store hardware addresses,
and ether_aton() to parse them, but more recent code generally uses
guint8 arrays, and the nm_utils_hwaddr_* methods, to be able to share
code between ETH_ALEN and INFINIBAND_ALEN cases. So update the old
code to match the new. (In many places, this ends up getting rid of
casts between struct ether_addr and guint8* anyway.)
(Also, in some places, variables were switched from struct ether_addr
to guint8[] a while back, but some code still used "&" when referring
to them even though that's unnecessary now. Clean that up.)
NMIP[46]Route had a "source" field, but it was always set to KERNEL
for routes read from the kernel (even if they were originally added by
NM).
Fix things a bit by translating between our "source" field and the
kernel's "protocol" field.
https://bugzilla.gnome.org/show_bug.cgi?id=729203
In this case, the fake platform implementation was wrong in that it did
not set the source property of the route/address objects like linux
platform does. Fix the test and the fake platform.
https://bugzilla.gnome.org/show_bug.cgi?id=706293
Signed-off-by: Thomas Haller <thaller@redhat.com>
When adding a link, the Linux platform implementation raises the
link-changed signal synchronously. Fix the fake platform to behave identically
and also fix all the tests.
This also fixes the Linux platform tests for the most part because now the
test functions (and fake platform) behave like the Linux system
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=706293
Co-Authored-By: Thomas Haller <thaller@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add an additional address parameter to link_add/bridge_add, to set the
MAC address of software devices.
https://bugzilla.gnome.org/show_bug.cgi?id=729844
Signed-off-by: Thomas Haller <thaller@redhat.com>
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>
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.
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.
Before, nm_platform_ip4_address_exists(), et al. look into the cache to see
whether the address/route already exists and returned an error if it
did.
Change the semantic of the delete functions, to return success in case of
"nothing to delete". Also always try to delete the object in the
kernel. The reason is, that the cache might be out of date and the
caller really wants to delete it. So, to be sure, we always delete.
In most cases the object is actually in the cache (because that is
how the caller came to know that such an object might exist).
In those cases, the lookup was not useful either, because the object
was actually cached.
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>
