When asking for the preshared-key for WireGuard peers, the secret request
will be very verbose with redundant information. Allow suppressing the entry
id from the prompt.
Just calling nm_connection_verify() is not correct. We need
nm_connection_normalize() because otherwise we miss out on places
where we have common normalization steps implemented to fix a
connection. This is also what server-side is done.
Revert the patch, as it breaks CI tests.
I wonder also whether this is the right place. There are already
several places in "clients/cli/connections.c" that call verify()
and normalize(). These places should be unified so that there is
one place where we complete the connection. And it probably should be
done as a separate step before the add_new_connection()/update_connection()
calls.
This reverts commit ca58bcca0c.
And, while at that, add a hint to the developer adding new items. It's
helps avoid a mistake that I believe is common (because I just made it
twice...).
Most of the times we actually need a NMSecretAgentSimple typed pointer.
This way, need need to cast less.
But even if we would need to cast more, it's better to have pointers
point to the actual type, not merely to avoid shortcomings of C.
In most cases, we don't want the translated string (only marked
for translation, and then programatically the caller deciedes
whether to translate or not).
The few places that always call gettext() can do it explicitly.
Now, that our functions are all "no_l10n" by default, rename them.
The state handling in add_and_activate_cb() and connect_device_cb() is
redundant to connected_state_cb() and in fact executed only if the
activation is really really really quick (which it never is).
Also, the return_text those implementations provide is different from
what connected_state_cb(), potentially confusing the users and adding
extra work for translators.
Not to mention extra lines of code, reading whose wastes our precious
time on the planet we could spend doing heroin instead.
Try to locate an existing connection before creating a new one when
handling "nmcli device wifi connect". This allows WPA-Enterprise
networks to be activated this way, consistent with the comment that this
command is equivalent to clicking on an SSID in a GUI client.
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
Correct the spelling across the *entire* tree, including translations,
comments, etc. It's easier that way.
Even the places where it's not exposed to the user, such as tests, so
that we learn how is it spelled correctly.
In general we want to keep the connections that the user is most likely
to want to see topmost. Default connections should be close to the top,
but the connections that are likely to have been brought up manually
shall be above them. It applies to VPN connections and should apply to
Hotspots too.
In editor_menu_main(), after saving a connection we wait that the
Update2() D-Bus call returns and then we copy the NMRemoteConnection
instance over to @connection.
This assumes that when Update2() returns the remote connection
instance is already updated with new settings. Indeed, on server side
the NMSettingsConnection first emits the "Updated" signal and then
returns to Update2(). However, the Updated signal doesn't include the
new setting values and so libnm has to fire an asynchronous
nmdbus_settings_connection_call_get_setting() to fetch the new
settings, which terminates after the Update2().
So, to be sure that the remote connection got updated we have also to
listen to the connection-changed signal, which is always emitted after
an update.
https://bugzilla.redhat.com/show_bug.cgi?id=1546805
Connection secrets are lost after calling
nm_connection_replace_settings_from_connection() because @con_tmp
doesn't contain secrets; refetch them like we do when starting the
editor.
We support all of these:
nmcli -v
nmcli -version
nmcli --version
Change the help output to display the first and last versions for
options, since they are the most common ones for command line tools.
Otherwise readline decides to initialize terminal handling at the first
readline call, and if that happens at the point it sees our
non-echoing rl_redisplay.
At that point, unless already intialized, readline wrongly convinces itself we
do our own handling of terminal peculiarities (such as cursor movement, or
erases). We do not -- we merely wrap the stock rl_redisplay(), temporarily
hiding the actual characters.
The rl_initialize() in nmc_readline_echo()s fixes broken line editing in
password prompts that weren't preceded a previous non-password prompt.
The other one is there for consistency only. (I guess we should be
initializing readline before use anyway; although it seems to initialize
itself anyway if we fail to do so...)
https://github.com/NetworkManager/NetworkManager/pull/241
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
If the activation fails even before the active connection instance is
created, we get the following:
$ nmcli connection up vpn1
libnm-CRITICAL **: nm_active_connection_get_connection: assertion 'NM_IS_ACTIVE_CONNECTION (connection)' failed
nmcli-CRITICAL **: active_connection_hint: assertion 'connection' failed
Error: Connection activation failed: Not authorized to control networking.
Check that we have an active connection before showing the hint.
Fixes: bc6c042d54
Globals are bad. Don't let nmc_readline_helper() access
nm_cli.
Instead, pass nmc_config along. nmc_config albeit being
a complex struct, is much more begning:
- the configuration nmc_config is initialized early on
and afterwards immutable.
- it only contains simple fields, which affect the behavior.
- it's not a global. While passing around the complex configuration
struct, it is clear that all callpaths don't access additional
global information.
