Testing WWAN connections through a Nokia Series 40 phone, addresses of family
AF_PHONET end up triggering an assert() in object_has_ifindex(), just because
object_type_from_nl_object() only handles AF_INET and AF_INET6 address.
In order to avoid this kind of problems, we'll try to make sure that the object
caches kept by NM only store known object types.
https://bugzilla.gnome.org/show_bug.cgi?id=742928
Connect: ppp0 <--> /dev/ttyACM0
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 5 / phase 'establish'
NetworkManager[27434]: <info> (ppp0): new Generic device (driver: 'unknown' ifindex: 12)
NetworkManager[27434]: <info> (ppp0): exported as /org/freedesktop/NetworkManager/Devices/4
[Thread 0x7ffff1ecf700 (LWP 27439) exited]
NetworkManager[27434]: <info> (ttyACM0): device state change: ip-config -> deactivating (reason 'user-requested') [70 110 39]
Terminating on signal 15
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 10 / phase 'terminate'
**
NetworkManager:ERROR:platform/nm-linux-platform.c:1534:object_has_ifindex: code should not be reached
Program received signal SIGABRT, Aborted.
0x00007ffff4692a97 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff4692a97 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff4693e6a in abort () from /usr/lib/libc.so.6
#2 0x00007ffff4c8d7f5 in g_assertion_message () from /usr/lib/libglib-2.0.so.0
#3 0x00007ffff4c8d88a in g_assertion_message_expr () from /usr/lib/libglib-2.0.so.0
#4 0x0000000000472b91 in object_has_ifindex (object=0x8a8320, ifindex=12) at platform/nm-linux-platform.c:1534
#5 0x0000000000472bec in check_cache_items (platform=0x7fe8a0, cache=0x7fda30, ifindex=12) at platform/nm-linux-platform.c:1549
#6 0x0000000000472de3 in announce_object (platform=0x7fe8a0, object=0x8a8c30, change_type=NM_PLATFORM_SIGNAL_REMOVED, reason=NM_PLATFORM_REASON_EXTERNAL) at platform/nm-linux-platform.c:1617
#7 0x0000000000473dd2 in event_notification (msg=0x8a7970, user_data=0x7fe8a0) at platform/nm-linux-platform.c:1992
#8 0x00007ffff5ee14de in nl_recvmsgs_report () from /usr/lib/libnl-3.so.200
#9 0x00007ffff5ee1849 in nl_recvmsgs () from /usr/lib/libnl-3.so.200
#10 0x00000000004794df in event_handler (channel=0x7fc930, io_condition=G_IO_IN, user_data=0x7fe8a0) at platform/nm-linux-platform.c:4152
#11 0x00007ffff4c6791d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#12 0x00007ffff4c67cf8 in ?? () from /usr/lib/libglib-2.0.so.0
#13 0x00007ffff4c68022 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#14 0x00000000004477ee in main (argc=1, argv=0x7fffffffeaa8) at main.c:447
(gdb) fr 4
#4 0x0000000000472b91 in object_has_ifindex (object=0x8a8320, ifindex=12) at platform/nm-linux-platform.c:1534
1534 g_assert_not_reached ();
refresh_object() raised a spurious change event for the route we
are about to delete. Suppress that by adding an internal reason flag.
Fixes: 41e6c4fac1
Deleting routes with metric 0 might end up deleting other
routes with a different metric.
Workaround this in platform to only delete a route with
metric 0 if such a route can be found prior to deletion.
Don't only look into the cache (which might be out of date).
Instead refetch the route we are about to delete to be sure.
There is still a race that we might end up deleting the wrong
route.
https://bugzilla.gnome.org/show_bug.cgi?id=741871https://bugzilla.redhat.com/show_bug.cgi?id=1172780
This match-any behavior ignoring metric is nowhere used. And even if we
would need such a behavior, using 0 is wrong because IPv4 routes can
have a metric of zero.
Handling a route with metric 0 effectively means
a metric of 1024 (user default). Adjust the add(),
delete() and exist() functions to consider routes
with metric 0 as 1024.
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
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.)
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>
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.
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).
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>
At some places, we considered a default route to be a route with
destination network 0.0.0.0 (::). This is wrong because a default route
is a route with plen==0.
This is for example relevant for OpenVPN which adds two routes
0.0.0.0/1 and 128.0.0.0/1 to hijack the default route. We should
not treat 0.0.0.0/1 as default route, instead NM should treat
it as any other subnet route (even if it effectively routes large
parts).
Signed-off-by: Thomas Haller <thaller@redhat.com>
'address' was not initialized, so using address.ifindex was not
going to work.
==6777== Conditional jump or move depends on uninitialised value(s)
==6777== at 0x44A6DB: check_cache_items (nm-linux-platform.c:1510)
==6777== by 0x44AA4F: announce_object (nm-linux-platform.c:1586)
==6777== by 0x44A59A: refresh_object (nm-linux-platform.c:1666)
==6777== by 0x44A676: check_cache_items (nm-linux-platform.c:1517)
==6777== by 0x44A812: announce_object (nm-linux-platform.c:1566)
==6777== by 0x44D957: handle_udev_event (nm-linux-platform.c:3964)
==6777== by 0x3BAFC125A7: g_closure_invoke (gclosure.c:777)
==6777== by 0x3BAFC2465C: signal_emit_unlocked_R (gsignal.c:3586)
==6777== by 0x3BAFC2C3E1: g_signal_emit_valist (gsignal.c:3330)
==6777== by 0x3BAFC2C69E: g_signal_emit (gsignal.c:3386)
==6777== by 0x3D93A03BE3: ??? (in /usr/lib64/libgudev-1.0.so.0.1.3)
==6777== by 0x3BAF8521D5: g_main_context_dispatch (gmain.c:3066)
The kernel adds these for various operations; they are short-lived,
added often, and not useful to NetworkManager. Ignore them. This
prevents NetworkManager from continuously updating the IPv6 config
and emitting state changes to clients via D-Bus for useless changes.
When starting, the initally loaded addresses were not fixed to have
absolute lifetimes.
This also leads to a crash due to failed assertion[1], when having
already expired addresses during NetworkManager start.
[1] backtrace:
#0 0x00007f39db91ec39 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007f39db920348 in __GI_abort () at abort.c:89
#2 0x00007f39dc35a0ed in _g_log_abort () at gmessages.c:255
#3 0x00007f39dc377c97 in g_assertion_message (domain=domain@entry=0x7f39e0085c67 "NetworkManager", file=file@entry=0x7f39e007f070 "platform/nm-linux-platform.c", line=line@entry=1146,
func=func@entry=0x7f39e0081430 <__FUNCTION__.23775> "_init_ip_address_lifetime", message=message@entry=0x7f39e13828b0 "assertion failed: (a_preferred <= a_valid && a_valid > 0 && a_preferred > 0)") at gtestutils.c:2278
#4 0x00007f39dc377cfa in g_assertion_message_expr (domain=domain@entry=0x7f39e0085c67 "NetworkManager", file=file@entry=0x7f39e007f070 "platform/nm-linux-platform.c", line=line@entry=1146,
func=func@entry=0x7f39e0081430 <__FUNCTION__.23775> "_init_ip_address_lifetime", expr=expr@entry=0x7f39e007f4e8 "a_preferred <= a_valid && a_valid > 0 && a_preferred > 0") at gtestutils.c:2293
#5 0x00007f39e0004608 in _init_ip_address_lifetime (address=address@entry=0x7fff7f8a2580, rtnladdr=rtnladdr@entry=0x7f39e12cdb20) at platform/nm-linux-platform.c:1144
#6 0x00007f39e0004ae4 in init_ip6_address (address=address@entry=0x7fff7f8a2580, rtnladdr=rtnladdr@entry=0x7f39e12cdb20) at platform/nm-linux-platform.c:1216
#7 0x00007f39e000a75e in ip6_address_get_all (platform=<optimized out>, ifindex=3) at platform/nm-linux-platform.c:3342
#8 0x00007f39e0032729 in nm_ip6_config_capture (ifindex=ifindex@entry=3, capture_resolv_conf=capture_resolv_conf@entry=0, use_temporary=use_temporary@entry=NM_SETTING_IP6_CONFIG_PRIVACY_UNKNOWN) at nm-ip6-config.c:303
#9 0x00007f39dffee8fa in update_ip_config (self=0x7f39e1380300, initial=<optimized out>) at devices/nm-device.c:5841
#10 0x00007f39dffef52a in nm_device_capture_initial_config (dev=<optimized out>) at devices/nm-device.c:5869
#11 0x00007f39e003e74e in get_existing_connection (manager=manager@entry=0x7f39e132b150, device=device@entry=0x7f39e1380300) at nm-manager.c:1576
#12 0x00007f39e003edb2 in add_device (self=self@entry=0x7f39e132b150, device=device@entry=0x7f39e1380300, generate_con=<optimized out>) at nm-manager.c:1826
#13 0x00007f39e003f503 in platform_link_added (reason=<optimized out>, plink=0x7f39e1372340, ifindex=3, self=0x7f39e132b150) at nm-manager.c:2205
#14 platform_link_cb (platform=<optimized out>, ifindex=3, plink=0x7f39e1372340, change_type=<optimized out>, reason=<optimized out>, user_data=<optimized out>) at nm-manager.c:2220
#15 0x00007f39da868d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#16 0x00007f39da8686bc in ffi_call (cif=cif@entry=0x7fff7f8a2a40, fn=0x7f39e003f360 <platform_link_cb>, rvalue=0x7fff7f8a29b0, avalue=avalue@entry=0x7fff7f8a2930) at ../src/x86/ffi64.c:522
#17 0x00007f39dc84aad8 in g_cclosure_marshal_generic (closure=0x7f39e1368080, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454
#18 0x00007f39dc84a298 in g_closure_invoke (closure=0x7f39e1368080, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7fff7f8a2c40, invocation_hint=invocation_hint@entry=0x7fff7f8a2be0)
at gclosure.c:777
#19 0x00007f39dc85c35d in signal_emit_unlocked_R (node=node@entry=0x7f39e12c16c0, detail=detail@entry=0, instance=instance@entry=0x7f39e12c30a0, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff7f8a2c40) at gsignal.c:3586
#20 0x00007f39dc8640f2 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff7f8a2e20) at gsignal.c:3330
#21 0x00007f39dc8643af in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3386
#22 0x00007f39e000e24c in nm_platform_query_devices () at platform/nm-platform.c:330
#23 0x00007f39e0040f30 in nm_manager_start (self=0x7f39e132b150) at nm-manager.c:4207
#24 0x00007f39dffe53ab in main (argc=1, argv=0x7fff7f8a3468) at main.c:657
Regression introduced by commit 8310a039d8.
https://bugzilla.gnome.org/show_bug.cgi?id=732472
Signed-off-by: Thomas Haller <thaller@redhat.com>
There is no point in raising events that a route/address was added, if
a subsequent call to ip4_address_get_all() et.al don't show these
objects.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Previous patch 8310a039d8 modified
platform to set the timestamp of addresses always to 1.
So, when adding an address platform logging looked like:
signal: address 4 added: 192.168.232.3/24 lft 2000sec pref 1000sec lifetime 12345-1[13344,14344] dev em1 src kernel
This is confusing in the log file and during debugging. Instead set the
timestamp to the last modification time of the address so that it will
look like:
signal: address 4 added: 192.168.232.3/24 lft 2000sec pref 1000sec lifetime 12345-12345[1000,2000] dev em1 src kernel
Signed-off-by: Thomas Haller <thaller@redhat.com>
When setting the timestamp to 1, we have to subtract(!) one second
from a_valid and a_preferred.
Due to this error, NM saw the lifetimes of addresses from system as two
seconds larger then the actual value.
Signed-off-by: Thomas Haller <thaller@redhat.com>
CC nm-linux-platform.lo
platform/nm-linux-platform.c: In function '_nm_platform_link_get':
platform/nm-linux-platform.c:161:17: error: 'rtnllink' may be used uninitialized in this function [-Werror=maybe-uninitialized]
nl_object_put (*object);
^
platform/nm-linux-platform.c:1923:35: note: 'rtnllink' was declared here
auto_nl_object struct rtnl_link *rtnllink;
^
cc1: all warnings being treated as errors
Signed-off-by: Thomas Haller <thaller@redhat.com>
When only the lifetime of an address changes, we did not get a platform signal
as libnl does not consider the time fields in nl_object_diff().
Workaround by comparing the timestamps manually.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Moving setting the source of the address to the init_* functions.
This also has the advantage, that the platform internal to_string functions have the proper
source set.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The kernel tells the address lifetimes in the 'struct ifa_cacheinfo'
attribute. This contains two timestamps (cstamp and tstamp) and two
relative lifetimes (ifa_prefered and ifa_valid).
The timestamps are equal to clock_gettime(CLOCK_MONOTONIC) scale in
1/100th of a second (wrapping every 497 days).
The preferred/valid times are re-adjusted everytime when sending the
message and count down as the time goes by. In other words, they are
anchored relatively to the moment of when kernel creates the netlink
message.
As platform is caching the rtnl_addr object, the information of *when* the
lifetimes started counting is not available.
This patch fixes reading these values by hacking the libnl object
when it gets received, so that valid and preferred are instead absolute
expiration timestamps in scale nm_utils_get_monotonic_timestamp_s() --
which NM internally is used for address timestamps.
There are two minor downsides to this hack:
- the valid and preferred properties of a cached rtnl_addr object have
an unexpected meaning, i.e. they are absolute and in a different time
scale.
- later when converting rtnl_addr to NMPlatformIPAddress, the base
timestamp is set to "1", i.e. an NMPlatformIPAddress has no knowledge
of when the address was created or last modified. The timestamp
property of NMPlatformIPAddress is solely there to anchor the relative
timestamps lifetime and preferred. Do not use it for anything
else.
Another reason the timestamp property is meaningless is that
its scale nm_utils_get_monotonic_timestamp_s() starts counting at
process start. So addresses that existed before would have a negative
or zero timestamp, which we avoid. This in turn could be solved by either
allowing negative timestamps or by shifting
nm_utils_get_monotonic_timestamp_*(). Both is viable, but not
necessary (ATM), because the age of an address has no other apparent
use then to anchor the relative timestamps.
Another implication is, that we potentially could get rid of the
timestamp completely, and insteat make preferred and lifetime be
absolute expiries.
This will be fixed properly later, by not caching libnl objects but instead
native NMPlatform objects. For those we have full control over their properties.
https://bugzilla.gnome.org/show_bug.cgi?id=727382
Signed-off-by: Thomas Haller <thaller@redhat.com>
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
The handling for announcing links was broken resulting in
duplicate link-added signals from platform.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
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>
