If we have NM running, adding a route with metric 20 might conflict
and cause NM to remove the route.
Choose a different (higher) metric that is less likely to cause a
conflict.
(cherry picked from commit b169f222bf)
platform/nm-linux-platform.c: In function 'setup':
platform/nm-linux-platform.c:4364:2: error: 'object' undeclared (first use in this function)
object = nl_cache_get_first (priv->link_cache);
^
Fixes 2b8060b9b3
This reverts commit efd09845c4.
It turns out that the socket space might not be the only buffer that may get
too full. 128K ought to be enough for it and we should resynchronize with the
kernel now if needed.
Kernel can return ENOBUFS in variety of reasons. If that happens, we know we've
lost events and should pick up kernel state.
Simple reproducer that triggers an ENOBUFS condition no matter how big our
netlink socket buffer is:
ip link add bridge0 type bridge
for i in seq $(0 1023); do ip link add dummy$i type dummy; \
ip link set dummy$i master bridge0; done
ip link del bridge0
We assume that in nm_nl_cache_search() and correctly set that in
get_kernel_object(), but we rtnl_link_alloc_cache() can initialize the cache
with devices of other families.
The consequence is that we don't notify when the bridge changes to IFF_UP as we
fail to match and remove the old downed object from the cache:
nm_device_bring_up(): [0xf506c0] (bridge0): bringing up device.
nm_platform_link_set_up(): link: setting up 'bridge0' (12)
link_change_flags(): link: change 12: flags set 'up' (1)
get_kernel_object(): get_kernel_object for link: bridge0 (12, family 7)
log_link(): signal: link added: 12: bridge0 <UP> mtu 1500 bridge driver 'bridge' udi '/sys/devices/virtual/net/bridge0'
get_kernel_object(): get_kernel_object for link: bridge0 (12, family 7)
log_link(): signal: link changed: 12: bridge0 <UP> mtu 1500 bridge driver 'bridge' udi '/sys/devices/virtual/net/bridge0'
log_link(): signal: link changed: 12: bridge0 <UP> mtu 1500 bridge driver 'bridge' udi '/sys/devices/virtual/net/bridge0'
(bridge0): device not up after timeout!
(bridge0): preparing device
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
For IPv4, iproute for example defaults to a metric of 0.
Hence, the name NM_PLATFORM_ROUTE_METRIC_DEFAULT was misleading.
Also add a NM_PLATFORM_ROUTE_METRIC_DEFAULT_IP4 define for completeness.
https://bugzilla.gnome.org/show_bug.cgi?id=740780
For IPv4 addresses, the kernel automatically adds a route when
configuring an IP address. Unfortunately, there is no way to control
this behavior or to set the route metric.
Fix this, by adding our own route and removing the kernel provided
one.
Note that this adds a major change in that we no longer call
nm_ip4_config_commit() for assumed devices.
https://bugzilla.gnome.org/show_bug.cgi?id=723178
Signed-off-by: Thomas Haller <thaller@redhat.com>
The upstream kernel added module aliases for nl80211 in commit
fb4e156886ce6e8309e912d8b370d192330d19d3, so querying nl80211
now auto-loads the module. Previously NM was doing this to
determine whether an ethernet-like device was a Wi-Fi device
that supported nl80211, but this leads to the nl80211 loading
on platforms that will never have or use Wi-Fi.
Since every nl80211-capable device will already have
DEVTYPE=wlan set (from /sys/class/net/wlan0/uevent), we can use
that as an indicator that the ethernet-like device is WiFi
instead of asking nl80211.
https://bugzilla.gnome.org/show_bug.cgi?id=740131
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.)
These lines are part of NM for a very long time.
I think they are wrong, because the default route is not
added to the NMIP4Config/NMIP6Config objects.
Signed-off-by: Thomas Haller <thaller@redhat.com>
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>
As we use NMLinkType in NetworkManagerUtils.h, we cannot use
the utils header without nm-platform.h. That is clearly wrong.
Apparently NMLinkType has a wider use outside of platform (and
its name is not prefixed with 'platform' either).
Move the enum definition to nm-types.h.
Signed-off-by: Thomas Haller <thaller@redhat.com>
They are defined as gint32 but are assigned a guint32 value and
then immediately passed back to the caller of _address_get_lifetime()
as guint32. They can never be negative, and may receive values
greater than G_MAXINT32, so they should be unsigned.
Kernel treats IPv6 route metrics with value zero (0) special.
Add a utility function that helps accounting for that.
Signed-off-by: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=738590
NMIP4Configs and NMIP6Configs are never supposed to contain a default
route, and thus nm_platform_ip6_route_sync() should never have to deal
with one. Unfortunately, if it *does* get passed a default route, it
will add it even if it was already there. This will result in an
RTM_NEWROUTE notification, which will cause NMPlatform to emit
ip6-route-changed, which will result in NMDevice doing some work and
then calling nm_ip6_config_commit(), which will result in NMIP6Config
passing the same list of routes to nm_platform_ip6_route_sync() again,
including the default route, which will cause NMPlatform to add the
route again...
(Something eventually causes this cycle to get broken, but it starts
up again the next time NM receives an RA.)
Fix this by having the route_sync() functions never add/modify the
default route (They were already not deleting it.)
vxlan_info_data_parser() must take care of missing netlink attributes.
Otherwise, older kernels will crash NM.
Also, workaround compilation against old kernel headers which are
missing 'struct ifla_vxlan_port_range'. We do this by defining our
own 'struct nm_ifla_vxlan_port_range' version.
Reported-by: Javier Jardón <jjardon@gnome.org>
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>
Seems like 128k is not enough for systems with many interfaces. This adds 4k
per device, while keeping the 128k minimum. Therefore this change only
affects systems with more than 32 interfaces.
https://bugzilla.redhat.com/show_bug.cgi?id=1141256
This patch requires both upstream kernel support for
IFLA_INET6_ADDR_GEN_MODE which was merged in this patch:
ipv6: addrconf: implement address generation modes
bc91b0f07ada5535427373a4e2050877bcc12218
and corresponding libnl support, merged in these patches:
veth: add kernel header linux/veth.h for VETH defines
9dc6e6da90016a33929f262bea0187396e1a061b
link: update copy of kernel header include/linux/if_link.h
b51815a9dbd8e45fd2558bbe337fb360ca2fd861
link/inet6: add link IPv6 address generation mode support
558f966782539f6d975da705fd73cea561c9dc83
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.
Previously, src/nm-ip4-config.h, libnm/nm-ip4-config.h, and
libnm-glib/nm-ip4-config.h all used "NM_IP4_CONFIG_H" as an include
guard, which meant that nm-test-utils.h could not tell which of them
was being included (and so, eg, if you tried to include
nm-ip4-config.h in a libnm test, it would fail to compile because
nm-test-utils.h was referring to symbols in src/nm-ip4-config.h).
Fix this by changing the include guards in the non-API-stable parts of
the tree:
- libnm-glib/nm-ip4-config.h remains NM_IP4_CONFIG_H
- libnm/nm-ip4-config.h now uses __NM_IP4_CONFIG_H__
- src/nm-ip4-config.h now uses __NETWORKMANAGER_IP4_CONFIG_H__
And likewise for all other headers.
The two non-"nm"-prefixed headers, libnm/NetworkManager.h and
src/NetworkManagerUtils.h are now __NETWORKMANAGER_H__ and
__NETWORKMANAGER_UTILS_H__ respectively, which, while not entirely
consistent with the general scheme, do still mostly make sense in
isolation.
Include <linux/if_ether.h> and <linux/if_infiniband.h> from
nm-utils.h, to get ETH_ALEN and INFINIBAND_ALEN, and remove those
includes (as well as <net/ethernet.h> and <netinet/ether.h>, and
various headers that had been included to get the ARPHRD_* constants)
from other files where they're not needed now.
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.)
Drop the arptype-based nm_utils_hwaddr funcs, and rename the
length-based ones to no longer have _len in their names. This also
switches nm_utils_hwaddr_atoba() to using a length rather than an
arptype, and adds a length argument to nm_utils_hwaddr_valid() (making
nm_utils_hwaddr_valid() now a replacement for nm_utils_hwaddr_aton()
in some places, where we were only using aton() to do validity
checking).
This test is quite broken and fails often. It does not fail
always, but the changes for a failure are high.
We certainly should fix that, but for now exclude the test from
`make check`.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add NetworkManager.h, which includes all of the other NM header, and
require all external users of libnm to use that rather than the
individual headers.
(An exception is made for nm-dbus-interface.h,
nm-vpn-dbus-interface.h, and nm-version.h, which can be included
separately.)
"NetworkManager.h"'s name (and non-standard capitalization) suggest
that it's some sort of high-level super-important header, but it's
really just low-level D-Bus stuff. Rename it to "nm-dbus-interface.h"
and likewise "NetworkManagerVPN.h" to "nm-vpn-dbus-interface.h"
Since the API has not changed at this point, this is mostly just a
matter of updating Makefiles, and changing references to the library
name in comments.
NetworkManager cannot link to libnm due to the duplicated type/symbol
names. So it links to libnm-core.la directly, which means that
NetworkManager gets a separate copy of that code from libnm.so.
Everything else links to libnm.
gcc warns:
make[5]: Entering directory `./NetworkManager/src/platform/tests'
CC platform.o
platform.c: In function ‘do_ip6_route_add’:
platform.c:696:2: error: ‘plen’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return nm_platform_ip6_route_add (ifindex, NM_PLATFORM_SOURCE_USER,
^
platform.c: In function ‘do_ip6_route_delete’:
platform.c:724:2: error: ‘plen’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return nm_platform_ip6_route_delete (ifindex, network, plen, metric);
^
platform.c: In function ‘do_ip4_route_delete’:
[...]
Signed-off-by: Thomas Haller <thaller@redhat.com>
clang warns:
make[5]: Entering directory `./NetworkManager/src/platform/tests'
CC test_link_fake-test-link.o
test-link.c:133:1: error: control may reach end of non-void function [-Werror,-Wreturn-type]
}
^
test-link.c:191:10: error: declaration shadows a variable in the global scope [-Werror,-Wshadow]
char *stdout = NULL;
^
/usr/include/stdio.h:173:16: note: expanded from macro 'stdout'
#define stdout stdout
^
/usr/include/stdio.h:169:25: note: previous declaration is here
extern struct _IO_FILE *stdout; /* Standard output stream. */
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
Since kernel commit 8fe02e167efa8ed4a4503a5eedc0f49fcb7e3eb9,
the value NL80211_FREQUENCY_ATTR_NO_IR replaces PASSIVE_SCAN
and NO_IBSS. Hence their numerical values are identical and
cause the following compiler warning.
clang warns:
make[4]: Entering directory `./NetworkManager/src'
CC wifi-utils-nl80211.lo
platform/wifi/wifi-utils-nl80211.c:683:48: error: initializer overrides prior initialization of this subobject [-Werror,-Winitializer-overrides]
[NL80211_FREQUENCY_ATTR_NO_IBSS] = { .type = NLA_FLAG },
^~~~~~~~
platform/wifi/wifi-utils-nl80211.c:682:53: note: previous initialization is here
[NL80211_FREQUENCY_ATTR_PASSIVE_SCAN] = { .type = NLA_FLAG },
^~~~~~~~
Signed-off-by: Thomas Haller <thaller@redhat.com>
The variable is not actually unused, because it is used
to free the nl_object instance.
clang warns:
make[4]: Entering directory `./NetworkManager/src'
CC nm-linux-platform.lo
platform/nm-linux-platform.c:1746:35: error: unused variable 'obj_cleanup' [-Werror,-Wunused-variable]
auto_nl_object struct nl_object *obj_cleanup = obj;
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
Some subdirectories of src/ encapsulate large chunks of functionality,
but src/config/, src/logging/, and src/posix-signals/ are really only
separated out because they used to be built into separate
sub-libraries that were needed either for test programs, or to prevent
circular dependencies. Since this is no longer relevant, simplify
things by moving their files back into the main source directory.
