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)
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)
When a software device is removed by nmcli in parallel with a
disconnection, e.g.:
nmcli connection add type team ifname t1 con-name t1
sleep 1
nmcli connection down t1 & nmcli device delete t1
nmcli sometimes crashes in the following way:
...
Connection 't1' (e4701688-d1a9-4942-85f0-a2081e120023) successfully added.
Connection 't1' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/36)
Device 't1' successfully removed.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==15217==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000000b (pc 0x7fa6d92d1c9d bp 0x0000004ba260 sp 0x7ffffe6a6f40 T0)
==15217==The signal is caused by a READ memory access.
==15217==Hint: address points to the zero page.
0 0x7fa6d92d1c9c in g_string_truncate (/lib64/libglib-2.0.so.0+0x6ec9c)
1 0x7fa6d92d2d7b in g_string_printf (/lib64/libglib-2.0.so.0+0x6fd7b)
2 0x45a6d7 in delete_device_cb clients/cli/devices.c:2465
3 0x7fa6d9849289 in g_simple_async_result_complete /usr/src/debug/glib2-2.56.1-1.fc28.x86_64/gio/gsimpleasyncresult.c:802
4 0x7fa6dbaa9836 in device_delete_cb libnm/nm-device.c:2458
5 0x7fa6d985bcf3 in g_task_return_now /usr/src/debug/glib2-2.56.1-1.fc28.x86_64/gio/gtask.c:1148
6 0x7fa6d985c7a5 in g_task_return /usr/src/debug/glib2-2.56.1-1.fc28.x86_64/gio/gtask.c:1206
7 0x7fa6d989ca6c in reply_cb /usr/src/debug/glib2-2.56.1-1.fc28.x86_64/gio/gdbusproxy.c:2586
8 0x7fa6d985bcf3 in g_task_return_now /usr/src/debug/glib2-2.56.1-1.fc28.x86_64/gio/gtask.c:1148
9 0x7fa6d985c7a5 in g_task_return /usr/src/debug/glib2-2.56.1-1.fc28.x86_64/gio/gtask.c:1206
10 0x7fa6d98913c0 in g_dbus_connection_call_done /usr/src/debug/glib2-2.56.1-1.fc28.x86_64/gio/gdbusconnection.c:5722
11 0x7fa6d985bcf3 in g_task_return_now /usr/src/debug/glib2-2.56.1-1.fc28.x86_64/gio/gtask.c:1148
12 0x7fa6d985bd2c in complete_in_idle_cb /usr/src/debug/glib2-2.56.1-1.fc28.x86_64/gio/gtask.c:1162
13 0x7fa6d92ac0ea in g_idle_dispatch gmain.c:5535
14 0x7fa6d92af7cc in g_main_dispatch gmain.c:3177
15 0x7fa6d92afb97 in g_main_context_iterate gmain.c:3903
16 0x7fa6d92afec1 in g_main_loop_run (/lib64/libglib-2.0.so.0+0x4cec1)
17 0x472892 in main clients/cli/nmcli.c:1067
18 0x7fa6d8cc31ba in __libc_start_main (/lib64/libc.so.6+0x231ba)
19 0x4162b9 in _start (/usr/bin/nmcli+0x4162b9)
The reason is that after calling nm_device_delete_async() we also
listen for the manager device-removed signal. When the signal is
received, device_removed_cb() destroy the @info structure and calls
g_main_loop_quit (loop). However, if the delete_device_cb() callback
has already been dispatched it is executed anyway and it tries to
access a stale @info.
It makes little sense to listen for the device-removed signal since
the return value of nm_device_delete_async() already tells us whether
the device was removed successfully or not.
The only advantage would be that when the device goes away for other
reasons we can still return success, but that is racy and should not
be relied upon.
https://bugzilla.redhat.com/show_bug.cgi?id=1639208
(cherry picked from commit 6130a4561e)
(cherry picked from commit 8123c42e61)
If the hints parameter to the agent request wasn't empty, ask
specifically for the 802-1x keys listed in the hints and skip the
guessing. I didn't add human readable names for all of the 802-1x
settings, it could be useful to do for at least the three 802-1x
properties that add_8021x_secrets already knows about because
those may have translations.
(cherry picked from commit 1a6e53808d)
Now that nmcli initiates a scan before displaying Wi-Fi networks,
the stub service must properly support that as well.
For the moment, the stub service chooses "now" as LastScan timestamp.
This causes nmcli not to trigger a new scan, because nmcli gives
unstable output if multiple nmcli processes in parallel race to
trigger a Wi-Fi scan. That should be fixed.
(cherry picked from commit 56a0488bba)
When link auto-negotiation is enabled, by default the network device
advertises all the supported speed and duplex modes in order to
negotiate the fastest link speed with the remote endpoint.
It is possible anyway to configure the device to just advertise and
accept a subset of supported modes.
This could be useful to properly enforce gigabit speeds on Ethernet:
as stated in IEEE 802.3 specification, auto-negotiation is mandatory
for 1000Base-T and 10GBase-T standards.
Allow specific values to 802-3-ethernet.speed and 802-3-ethernet.duplex
properties also when 802-3-ethernet.auto-negotiate=yes: this will
result in link auto-negotiation advertising the specified speed/duplex
mode as the only one available.
It's not libnm's responsibility to hide the banner
depending on the VPN state. libnm should cache and expose
NetworkManager's state, and if the VPN connection has
a banner there, it should be returned.
The previous behavior was since ever in libnm, and in libnm-glib since
the banner was introduced in commit e5b834c1f9.
I think it's wrong if libnm tries too hard putting additional logic
on top of what is on D-Bus.
When a property getter returns an empty/missing strv-array, in multi-line
mode we should not print any lines.
To get that right, we must mark the cell as STRV type, even if there is no value
provided.
Previously, with text_out_flags having NM_META_ACCESSOR_GET_OUT_FLAGS_STRV
and value being NULL, we would not set
cell->text_format = PRINT_DATA_CELL_FORMAT_TYPE_STRV;
and thus, later on the value would be treated as a missing (plain)
string.
The property getter for certain properties tries to return
a strv array.
In this case, the result should be identical, whether an
empty strv array or NULL is returned.
Let _ip_config_get_routes() return %NULL if there are no routes.
This should have no practical difference, but it actually exposes
a bug in "cli/common/utils.c", which was previously hidden by
not commonly returning %NULL. This bug will be fixed in the
next commit.
Currently, nmcli does not sort the list of available connections
for display. Instead, it shows them in the order as NetworkManager
exposes them on D-Bus.
Previously, test-networkmanager-service.py, would generate the list
of available connections by iterating the connections dictionary.
In Python (at least until Python 3.6), the order when iterating over
dictionaries is undefined. This inconsistancy lets tests behave
differently depending on the python version. Possibly with Python
3.4 and 3.5, tests might even behave differently between individual
runs (since Python there uses siphash with a randomized hash seed).
It is safer to enable send-sci by default because, at the cost of
8-byte overhead, it makes MACsec work over bridges (note that kernel
also enables it by default). While at it, also make the option
configurable.
https://bugzilla.redhat.com/show_bug.cgi?id=1588041
Check the wpa_flags and rsn_flags values to see if the network needs the
password added to the 802-11-wireless-security settings. The current
ap_flags check alone would only trigger the password to be sent for WEP
networks. Also remove unneeded initialization of the three variables.
Commands that fail with G_DEBUG=fatal-warnings produce unstable
output like
(process:10743): GLib-CRITICAL **: 16:29:13.635: g_ptr_array_add: assertion 'rarray' failed
To workaround that, add a new option for marking the output as unstable.
An alternative might be to extend the replace_stdout, replace_stderr
arguments to support more powerful matching, like by specifying regular
expression for replacing. However, it's just too complicated. Add a simpler
workaround by passing _UNSTABLE_OUTPUT.
How does `nmcli -f ALL dev show $DEV` look, if it references
a connection that is invisible to the user?
Note in the output:
CONNECTIONS.AVAILABLE-CONNECTIONS[1]: (null) | (null)
At several places, "test-networkmanager-service.py" uses generated numbers
with a defined seed. For example, generated connection's UUID is
generated in a predictable, but randomized way (if you forgive the
inprecise use of the word "random" in context of using a deterministic
seed).
Aside the connection's UUID, this becomes more interesting in the next commit
where the stub server generates a list of IP and DHCP settings in a predictable
randomized way.
For "clients/tests" we spawn the test service multiple times, but also
create similar environments by calling init_001(). This is done for
convenience, where out of lazyness all the tests share one setup. But it's
still a good idea that these tests generate slightly different setups,
wherever applicable. this increases the possible setups which get tested.
For example, the number of static IPv4 addresses (the following commit) is
interested to explicitly test for zero or a non-zero number of
addresses. If all tests happen to use the same seed, the tests are expected
to also generate the same number of addresses, and we miss an opportunity to
hit interesting test cases.
There is still no guarantee that all interesting cases are hit, the chances are just
better. The approach of generating the setup randomly, does not preclude that
the stub-server allows to explicitly configure the setup. However, due to the
sheer number of combinations that might be interesting to test, it's much simpler
to rely on some randomization and have the justifid hope we catch interesting cases.
Also in terms of runtime of the test, the cli unit tests should complete within
few seconds. Testing every combination would result in huge tests and long runtimes.
Also, the patch refactors generating random numbers in
"test-networkmanager-service.py". For example, it introduces
Util.RandomSeed(), which can be used to generate a sequence of different
random numbers. It works by having an internal state and a counter which is
combined to chain the seed and generate different numbers on each call.
