#0 0x00007fffea7481e5 in _g_log_abort (breakpoint=1) at gmessages.c:554
#1 0x00007fffea74951d in g_logv (log_domain=0x7fffea78e00e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffcbb0)
at gmessages.c:1371
#2 0x00007fffea7496f3 in g_log
(log_domain=log_domain@entry=0x7fffea78e00e "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7fffea798320 "%s: assertion '%s' failed")
at gmessages.c:1413
#3 0x00007fffea749f2d in g_return_if_fail_warning
(log_domain=log_domain@entry=0x7fffea78e00e "GLib", pretty_function=pretty_function@entry=0x7fffea799d40 <__func__.4759> "g_atomic_ref_count_dec", expression=expression@entry=0x7fffea799ca1 "g_atomic_int_get (arc) > 0") at gmessages.c:2762
#4 0x00007fffea754c12 in g_atomic_ref_count_dec (arc=arc@entry=0x5555558c5280) at grefcount.c:260
#5 0x00007fffea7302c6 in g_hash_table_unref (hash_table=0x5555558c5240) at ghash.c:1101
#6 0x00007fffea4b6dbc in clear_op_res (simple=0x55555587ed90 [GSimpleAsyncResult]) at gsimpleasyncresult.c:248
#7 0x00007fffea4b6dbc in g_simple_async_result_finalize (object=0x55555587ed90 [GSimpleAsyncResult]) at gsimpleasyncresult.c:268
#8 0x00007fffea67b949 in g_object_unref (_object=<optimized out>) at gobject.c:3346
#9 0x00007fffea67b949 in g_object_unref (_object=0x55555587ed90) at gobject.c:3238
#10 0x00007fffe95dea2d in checkpoint_rollback_cb (object=<optimized out>, result=<optimized out>, user_data=0x55555587ed90) at libnm/nm-manager.c:1584
#11 0x00007fffea4ca834 in g_task_return_now (task=0x5555558b5c80 [GTask]) at gtask.c:1148
#12 0x00007fffea4cb196 in g_task_return (task=0x5555558b5c80 [GTask], type=<optimized out>) at gtask.c:1206
#13 0x00007fffea5096bb in reply_cb (connection=<optimized out>, res=<optimized out>, user_data=0x5555558b5c80) at gdbusproxy.c:2596
#14 0x00007fffea4ca834 in g_task_return_now (task=0x5555558b5d50 [GTask]) at gtask.c:1148
#15 0x00007fffea4cb196 in g_task_return (task=0x5555558b5d50 [GTask], type=<optimized out>) at gtask.c:1206
#16 0x00007fffea4fdd4a in g_dbus_connection_call_done (source=<optimized out>, result=0x5555558b5e20, user_data=0x5555558b5d50) at gdbusconnection.c:5715
#17 0x00007fffea4ca834 in g_task_return_now (task=0x5555558b5e20 [GTask]) at gtask.c:1148
#18 0x00007fffea4ca86d in complete_in_idle_cb (task=task@entry=0x5555558b5e20) at gtask.c:1162
#19 0x00007fffea73e97b in g_idle_dispatch (source=0x7fffdc04eb90, callback=0x7fffea4ca860 <complete_in_idle_cb>, user_data=0x5555558b5e20) at gmain.c:5620
#20 0x00007fffea74206d in g_main_dispatch (context=0x5555557c8410) at gmain.c:3182
#21 0x00007fffea74206d in g_main_context_dispatch (context=context@entry=0x5555557c8410) at gmain.c:3847
#22 0x00007fffea742438 in g_main_context_iterate (context=0x5555557c8410, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3920
#23 0x00007fffea742762 in g_main_loop_run (loop=0x55555584ed00) at gmain.c:4116
Fixes: c3efedf54b
(cherry picked from commit 25a3825b51)
(cherry picked from commit a505ab423e)
Since commit 9ecdba316 ('platform: create netlink messages directly
without libnl-route-3') we're unconditionally setting IFA_ADDRESS to
the peer address, even if there's no peer and it's all zeroes.
The kernel actually stopped caring somewhere around commit caeaba790
('ipv6: add support of peer address') in v3.10, but Ubuntu Touch likes
to run Android's v3.4 on some poorly supported hardware.
Fixes: 9ecdba316chttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/77
(cherry picked from commit ef6d461b7f)
(cherry picked from commit e2409b1888)
When the parent device has a device default route (i.e. without
gateway) and we establish a VPN on top of it, 'ip route get' for the
VPN gateway returns a device route, which is the same result we get
for an unreachable VPN gateway. However it is necessary to add the
route to the gateway or otherwise it will possibly become unreachable
once the VPN gets activated.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/93
(cherry picked from commit 797eab2f6b)
(cherry picked from commit 6808cd48aa)
When the supplicant does not support PMF we wrongly set
'ieee80211w=0', but since the option is not recognized the connection
fails. Don't set it when unsupported.
Fixes: a9ab50efb1
(cherry picked from commit 58c4cd9cc9)
(cherry picked from commit 542e340f01)
On RHEL, openvswitch package is not in the base set of packages. Hence,
we cannot depend NetworkManager-ovs package on openvswitch.
This isn't really a problem, because NetworkManager's OVS plugin must
anyway behave graceful when openvswich service is not running or not
available. It only means, that a user who wants to use the OVS plugin
needs to explicitly install the openvswitch package.
https://bugzilla.redhat.com/show_bug.cgi?id=1629178https://bugzilla.redhat.com/show_bug.cgi?id=1633190
(cherry picked from commit 669bd33022)
(cherry picked from commit f92d2d7766)
wpa_supplicant is going to change the global default for PMF from 0
(disabled) to 1 (optional) [1], so NM code needs to be adjusted to
work with all wpa_supplicant versions. Furthermore, it is better to
set optional PMF using the 'Pmf' property instead of the 'ieee80211w'
configuration option because the former better handles missing support
in driver [2].
Note that each interface in wpa_supplicant has its own copy of global
configuration and so 'global' options must still be set on each
interface. So, let's set Pmf=1 when each interface gets created and
override it with ieee80211w={0,2} if needed during association.
[1] http://lists.infradead.org/pipermail/hostap/2018-November/039009.html
[2] http://lists.infradead.org/pipermail/hostap/2019-January/039215.htmlhttps://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/104
(cherry picked from commit a9ab50efb1)
(cherry picked from commit 1110e0bcae)
When updating a connection passing agent-owned secret, they are lost
from @reread_connection after the settings-plugin persists the
connection. Therefore we need to cache and reapply them separately to
the connection so that they can be saved to secret agents later.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/82
(cherry picked from commit a3383726dc)
(cherry picked from commit 95d9fd387b)
Since we determine the connectivity state of each device individually,
the global connectivity state is an aggregate of all these states.
I am not sure about considering here devices that don't have the (best)
default route for their respective address family. But anyway.
When we aggregate the best connectivity, we chose the numerical largest
value. That is wrong, because PORTAL is numerically smaller than
LIMITED.
That means, if you have two devices, one with connectivity LIMITED and
one with connectivity PORTAL, then LIMITED wrongly wins.
Fixes: 6b7e9f9b22https://bugzilla.redhat.com/show_bug.cgi?id=1619873
(cherry picked from commit ade753d06f)
(cherry picked from commit d1e98e334d)
These directories don't exist yet, however are added by newer versions.
When switching branches, the artifacts from these directories wrongly
show up in `git status`. Ignore them.
The meta data type descriptor must set .get_gtype only for
GObject properties which are of type int or uint. That is, when
the enum type cannot be automatically detected.
However, NM_SETTING_SERIAL_PARITY is a g_param_spec_enum()
of type NM_TYPE_SETTING_SERIAL_PARITY, so setting the get_gtype()
hook is wrong and leads to a crash
$ /bin/nmcli connection add type gsm autoconnect no con-name t ifname '*' apn xyz serial.parity 5
(process:11086): libnmc-CRITICAL **: 15:04:35.180: file clients/common/nm-meta-setting-desc.c: line 1283 (_set_fcn_gobject_enum): should not be reached
Segmentation fault (core dumped)
That is because the enum property setter does:
»···if ( has_gtype
»··· && NM_IN_SET (gtype_prop,
»··· G_TYPE_INT,
»··· G_TYPE_UINT)
»··· && G_TYPE_IS_CLASSED (gtype)
»··· && (gtype_class = g_type_class_ref (gtype))
»··· && ( (is_flags = G_IS_FLAGS_CLASS (gtype_class))
»··· || G_IS_ENUM_CLASS (gtype_class))) {
»···»···/* valid */
meaning, it only allows "has_gtype" if the native "gtype_prop" is
G_TYPE_INT or G_TYPE_UINT.
Fixes: 9a68123827
(cherry picked from commit 127ac25ef8)
(cherry picked from commit 7c78398d3e)
libnm currently has only one GObject property of type uint64:
"serial.send-delay". However, it's broken because uint64 handling
is not implemented.
$ nmcli connection add type gsm autoconnect no con-name t ifname '*' apn 'xyz' serial.baud 5
Connection 't' (4c929f17-9fda-41d6-8f90-897f6d46b078) successfully added.
$ nmcli connection show t
...
ipv6.dhcp-duid: --
ipv6.dhcp-send-hostname: yes
ipv6.dhcp-hostname: --
ipv6.token: --
(process:14016): libnmc-CRITICAL **: 14:08:32.591: file clients/common/nm-meta-setting-desc.c: line 811 (_get_fcn_gobject_int): should not be reached
serial.baud: 5
serial.bits: 8
serial.parity: none
serial.stopbits: 1
serial.send-delay: --
gsm.number: *99#
...
$ nmcli connection add type gsm autoconnect no con-name t ifname '*' apn 'xyz' serial.baud 5 serial.send-delay 100
(process:14852): libnmc-CRITICAL **: 14:12:24.259: file clients/common/nm-meta-setting-desc.c: line 1131 (_set_fcn_gobject_int): should not be reached
Segmentation fault (core dumped)
Fixes: b6d9bdcee8
(cherry picked from commit a600b3a3b2)
(cherry picked from commit 1b987a5366)
The new hash table should destroy elements stolen from the hash table
returned by nm_utils_parse_variant_attributes().
Fixes: d094914120
(cherry picked from commit 31bda1b837)
(cherry picked from commit 6a9d2740ac)
When nm_device_disconnect_async() returns, the device could be still
in DEACTIVATING state, and so we also register to device-state signal
notifications to know when the device state goes to DISCONNECTED.
Sometimes it happens that the device state goes to DISCONNECTED before
nm_device_disconnect_async() returns. In this case the signal handler
exits the main loop and then the callback for disconnect_async() is
executed anyway because it was already dispatched, leading to an
invalid memory access.
To avoid this we should cancel nm_device_disconnect_async() when we
are quitting the main loop.
Reproducer:
nmcli connection add type team ifname t1 con-name t1
nmcli connection up t1
nmcli device disconnect t1 & nmcli device delete t1
Crash example:
==14955==ERROR: AddressSanitizer: SEGV on unknown address 0xffffffff0000000b (pc 0x7f128c8ba3dd bp 0x0000004be080 sp 0x7ffcda7dc6e0 T0)
==14955==The signal is caused by a READ memory access.
0 0x7f128c8ba3dc in g_string_truncate (/lib64/libglib-2.0.so.0+0x713dc)
1 0x7f128c8bb4bb in g_string_printf (/lib64/libglib-2.0.so.0+0x724bb)
2 0x45bdfa in disconnect_device_cb clients/cli/devices.c:2321
3 0x7f128ca3d1a9 in g_simple_async_result_complete /usr/src/debug/glib2-2.58.1-1.fc29.x86_64/gio/gsimpleasyncresult.c:802
4 0x7f128cf85d0e in device_disconnect_cb libnm/nm-device.c:2354
5 0x7f128ca4ff73 in g_task_return_now /usr/src/debug/glib2-2.58.1-1.fc29.x86_64/gio/gtask.c:1148
6 0x7f128ca508d5 in g_task_return /usr/src/debug/glib2-2.58.1-1.fc29.x86_64/gio/gtask.c:1206
7 0x7f128ca8ecfc in reply_cb /usr/src/debug/glib2-2.58.1-1.fc29.x86_64/gio/gdbusproxy.c:2586
8 0x7f128ca4ff73 in g_task_return_now /usr/src/debug/glib2-2.58.1-1.fc29.x86_64/gio/gtask.c:1148
9 0x7f128ca508d5 in g_task_return /usr/src/debug/glib2-2.58.1-1.fc29.x86_64/gio/gtask.c:1206
10 0x7f128ca83440 in g_dbus_connection_call_done /usr/src/debug/glib2-2.58.1-1.fc29.x86_64/gio/gdbusconnection.c:5713
11 0x7f128ca4ff73 in g_task_return_now /usr/src/debug/glib2-2.58.1-1.fc29.x86_64/gio/gtask.c:1148
12 0x7f128ca4ffac in complete_in_idle_cb /usr/src/debug/glib2-2.58.1-1.fc29.x86_64/gio/gtask.c:1162
13 0x7f128c893b7a in g_idle_dispatch gmain.c:5620
14 0x7f128c89726c in g_main_dispatch gmain.c:3182
15 0x7f128c897637 in g_main_context_iterate gmain.c:3920
16 0x7f128c897961 in g_main_loop_run (/lib64/libglib-2.0.so.0+0x4e961)
17 0x473afb in main clients/cli/nmcli.c:1067
18 0x7f128c6a1412 in __libc_start_main (/lib64/libc.so.6+0x24412)
19 0x416c39 in _start (/usr/bin/nmcli+0x416c39)
https://github.com/NetworkManager/NetworkManager/pull/254https://bugzilla.redhat.com/show_bug.cgi?id=1546061
(cherry picked from commit cf1126f60b)
(cherry picked from commit b64abe8572)
A lot of drivers actually support changing the MAC address of a link
without taking it down.
Taking down a link is very bad, because kernel will remove routes
and IPv6 addresses.
For example, if the user used a dispatcher script to add routes,
these will be lost. Note that we may change the MAC address of a
device any time. For example, a VLAN device watches the parent's
MAC address and configures it (with a logging message "parent hardware
address changed to ...").
Try first whether we can change the MAC address without taking the
link down. Only if that fails, retry with taking it down first.
https://bugzilla.redhat.com/show_bug.cgi?id=1639274
(cherry picked from commit e206a34732)
(cherry picked from commit ca4e28ea2b)
Add helper nm_platform_link_get_ifi_flags() to access the
ifi-flags.
This replaces the internal API _link_get_flags() and makes it public.
However, the return value also allows to distinguish between errors
and valid flags.
Also, consider non-visible links. These are links that are in netlink,
but not visible in udev. The ifi-flags are inherrently netlink specific,
so it seems wrong to pretend that the link doesn't exist.
(cherry picked from commit b445b1f8fe)
(cherry picked from commit f8a13422f1)
Working on NetworkManager 1.12.4 and sometimes (rarely), when creating
a NM client object before NetworkManager service start, this object will
never be running.
In that case, we can see the following log:
"[GLIB-GLib-GIO WARN] Error calling GetManagedObjects() when name
owner :1.5 for name org.freedesktop.NetworkManager came back:
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod:
No such interface 'org.freedesktop.DBus.ObjectManager' on object
at path /org/freedesktop".
Object Manager object shall be registered before requesting dbus name
to be sure that 'org.freedesktop.Dbus.ObjectManager' interface is present
when name owner change is received by libnm.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/51
(cherry picked from commit dc0cdbb57e)
(cherry picked from commit b2eb897bc0)
Sometimes the test fail:
$ make -j 10 src/platform/tests/test-address-linux
$ while true; do
NMTST_DEBUG=d ./tools/run-nm-test.sh src/platform/tests/test-address-linux 2>&1 > log.txt || break;
done
fails with:
ERROR: src/platform/tests/test-address-linux - Bail out! test:ERROR:src/platform/tests/test-common.c:790:nmtstp_ip_address_assert_lifetime: assertion failed (adr <= lft): (1001 <= 1000)
That is, because of a wrong check. Fix it.
(cherry picked from commit e180464bcc)
(cherry picked from commit 66cbca1f21)
After an update of the connection.mdns property, a reactivation is
needed to apply the new value.
Also, the ifcfg-rh variable name was wrong.
Fixes: 2e2ff6f27a
(cherry picked from commit 8e6ad2853c)
In certain cases the timeouts may not have been unref'ed before they
need to be re-added. Add the appropriate unref calls to ensure we don't
register the timeout multiple times.
This fixes possible cases where timeouts are triggered multiple times
and even on destroyed DHCPv6 clients.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/73
(cherry picked from commit e179202e47)
(cherry picked from commit bbef6cf44a)
This improves performance of fuzzer.
C.f. oss-fuzz#11019.
(cherry picked from commit 3c72b6ed4252e7ff5f7704bfe44557ec197b47fa)
(cherry picked from commit 50403cccee)
(cherry picked from commit f11f5abb1a)
