This is an interface to the Checkpoint/Restore functionality that's
available for quite some time. It runs a command with a checkpoint taken
and rolls back unless success is confirmed before the checkpoint times
out:
$ nmcli dev checkpoint eth0 -- nmcli dev dis eth0
Device 'eth0' successfully disconnected.
Type "Yes" to commit the changes: No
Checkpoint was removed.
The details about how it's used are documented in nmcli(1) and
nmcli-examples(7).
When the input ends, we indeed eventually want to shut down.
Nevertheless, it might be that we terminated the input *because* we're
already shutting down and want do do our cleanup. Let's not take the
shortcut to nmc_exit() in case the main loop is no longer running.
This doesn't affect existing uses of nmc_readline(), but will be useful
in a future patch.
This makes get_device_list() return an array of NMDevices with a
reference taken and a destroy notifier that unhooks disconnect_state_cb,
so that it could replace the GSList of the same utility used by
disconnect/delete commands.
Suggested-by: Thomas Haller <thaller@redhat.com>
A pointer array is slightly more efficient here, since we don't really
need the ability to insert elements in the middle. In fact, we'd prefer
if we could just add to the end, so that we'd spare some callers from a
need to do a g_slist_reverse().
Even though that alone being a good reason to use a GPtrArray instead of
GSList, I'm doing this for so that I could actually use the returned value
as-is in a call to nm_client_checkpoint_create() in a future patch.
Don't consider "--" a device name. Instead, treat it as a signal to stop
reading the device list.
If a caller expects nothing beyond the device names, it now has to
check.
Prior to this patch, get_device_list() would give the caller no clue
about how many options did it consume. That is okay -- it would always
process all argument until the end, so the no callers would really care.
In a further patch, I'd like to allow termination of the device name
list (with a "--" arguments), so it will be possible to specify further
arguments.
Let's change the protype of this routine to use pointers to argc/argv,
that it will be possible to adjust them.
Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.
To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled
Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled
The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.
The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).
Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
We want to warn the user if they're connecting to an insecure network:
$ nmcli d wifi
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
BA:00:6A:3C:C2:09 Secured Network Infra 2 54 Mbit/s 100 ▂▄▆█ WPA3
FA:7C:46:CC:9F:BE Ye Olde Wlan Infra 1 54 Mbit/s 100 ▂▄▆█ WEP
$ nmcli d wifi connect 'Ye Olde Wlan'
Warning: WEP encryption is known to be insecure.
...
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1224
The order of addresses matters. For "ipv4.addresses", the list
contains the primary address first. For "ipv6.addresses", the
order was reverted. This was also documented behavior.
The previous patch just changed behavior with respect to relative order
of static IPv6 addresses and autoconf6/DHCPv6. As we seem in the mood
for changing behavior, here is another one.
Now the addresses are interpreted in an order consistent with IPv4 and
how one might expect: preferred addresses first.
This adds a global "--offline" option and allows its use with "add" and
"modify" commands. The "add" looks like this:
$ nmcli --offline conn add type ethernet ens3 ipv4.dns 192.168.1.1 \
>output.nmconnection
The "modify" is essentially implementing what's been suggested by
Beniamino in bugzilla ticked (referred to below):
$ nmcli --offline connection modify ens3 ipv4.dns 192.168.1.1 \
<input.nmconnection >output.nmconnection
Other commands don't support the argument at the moment:
$ nmcli --offline c up ens3
Error: 'up' command doesn't support --offline mode.
https://bugzilla.redhat.com/show_bug.cgi?id=1361145
Make the order of nmc_complete_strings() arguments consistent with the
multi-way conditional below. Doesn't have any effect, just ensures the
ommisions and mistakes are hopefully easier to spot.
Use bitfields to save a few bytes. This involves swapping gboolean for
bool and some reordering in order to get them grouped together.
The patch looks horrible, because clang-format decides to put itself and
seem to go out of its way to make this whole file look idiotic.
What can you do.
When no radio hardware is present in the system, "nmcli radio"
currently displays:
WIFI-HW WIFI WWAN-HW WWAN
enabled enabled enabled enabled
which is misleading. Use the new RadioFlags property to display
"missing" in the *-HW columns when there is no hardware for the
given radio technology.
https://bugzilla.redhat.com/show_bug.cgi?id=1996918
If we can't find a connection for any reason other than that it doesn't
exist, we should error out immediately and consistently, regardless of
whether we already encountered a non-existent connection.
We sometimes emit warnings after a connection is added. Currently
there's a warning when the connection ID collides with another one (and
a suggestion to use an UUID instead).
Let's move the check into a separate routine, so that we can reuse it
elsewhere, such as on connection "modify" (in a following commit).
Check if a connection uses something that is likely not to work --
either now or in future.
The ultimate decision on whether it's going to work is up to the daemon.
We just use the result to color the connection differently to provide
slight visual cue to the user.
Follow-up commits are going color Wi-Fi networks and connections that rely
on deprecated features differently, to provide a visual cue.
Add color definitions for those.
We often create the source with default priority, no destroy function and
attach it to the default context (g_main_context_default()). For that
case, we have wrapper functions like nm_g_timeout_add_source()
and nm_g_idle_add_source(). Use those.
There should be no change in behavior.
Before, we would just ignore the errors when we passed an invalid value
to a property alias:
$ nmcli c add type ethernet mac Hello
Connection 'ethernet-1' (242eec76-7147-411a-a50b-336cf5bc8137) successfully added.
$ nmcli c show 242eec76-7147-411a-a50b-336cf5bc8137 |grep 802-3-ethernet.mac-address:
802-3-ethernet.mac-address: --
...or crash, because the GError would still be around:
$ nmcli c add type ethernet mac Hello ethernet.mac-address World
(process:734670): GLib-WARNING **: 14:52:51.436: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Error: failed to modify 802-3-ethernet.mac-address: 'World' is not a valid Ethernet MAC.
Error: failed to modify 802-3-ethernet.mac-address: 'Hello' is not a valid Ethernet MAC.
Now we catch it early enough:
$ nmcli c add type ethernet mac Hello
Error: failed to modify 802-3-ethernet.mac-address: 'Hello' is not a valid Ethernet MAC.
Fixes: 40032f4614 ('cli: fix resetting values via property alias')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1134
It's helpful to control when data/state gets mutated. In particular,
when passing on a pointer via several hops. C can help with that
at compile time via "const".
But the "index" field of APInfo is actually mutable, as it counts
the lines. So most of the data is immutable, but the index.
Make APInfo const. But to do that, the mutable part must be moved to a
separate place.
Also, start with the counter initialized to zero instead of one.
It is just nicer.
On the D-Bus API, the current access point is referred exactly, by its
D-Bus path. Likewise, in libnm's NMClient cache, the access point
instance is unique in representing the D-Bus object (meaning, we
can directly use pointer equality).
Let's not compare the active AP based on the BSSID. It can happen
that the scan list contains the same BSSID multiple times (for example
on different bands). In that case, the output should only highlight
one AP as in-use:
$ nmcli device wifi list
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
* E4:0f:4b:2a:c3:d1 MYSSID1 Infra 6 270 Mbit/s 100 ▂▄▆█ WPA2
* E4:0f:4b:2a:c3:d1 MYSSID1 Infra 6 270 Mbit/s 87 ▂▄▆█ WPA2
This is vestigal. It has been in place, because we'd be turning off echo
ourselves when asking for password and needed to make sure we'd still
terminal in original state upon unexpected termination.
This shouldn't be necessary since commit 9d95e1f175 ('clients/cli: use a
nicer password prompt') we let readline take care of this and also clean
up after itself in nmc_cleanup_readline().
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1100
When using the "remove" command on nmcli edit mode it will reset the
value to the default when no property value is specified. If the
property value is specified it will remove that specific property.
Example:
```
nmcli> set ethernet.wake-on-lan phy
nmcli> print ethernet.wake-on-lan
802-3-ethernet.wake-on-lan: phy, default
nmcli> remove ethernet.wake-on-lan default
nmcli> print ethernet.wake-on-lan
802-3-ethernet.wake-on-lan: phy
nmcli> remove ethernet.wake-on-lan
nmcli> print ethernet.wake-on-lan
802-3-ethernet.wake-on-lan: default
```
This patch introduces "add" command to nmcli edit mode. When using "add"
it will append the value to the ones already set. This is doing the same
thing than the "set" command does right now.
Example:
```
nmcli> add ipv4.addresses 192.168.1.1/24
```
We use clang-format for automatic formatting of our source files.
Since clang-format is actively maintained software, the actual
formatting depends on the used version of clang-format. That is
unfortunate and painful, but really unavoidable unless clang-format
would be strictly bug-compatible.
So the version that we must use is from the current Fedora release, which
is also tested by our gitlab-ci. Previously, we were using Fedora 34 with
clang-tools-extra-12.0.1-1.fc34.x86_64.
As Fedora 35 comes along, we need to update our formatting as Fedora 35
comes with version "13.0.0~rc1-1.fc35".
An alternative would be to freeze on version 12, but that has different
problems (like, it's cumbersome to rebuild clang 12 on Fedora 35 and it
would be cumbersome for our developers which are on Fedora 35 to use a
clang that they cannot easily install).
The (differently painful) solution is to reformat from time to time, as we
switch to a new Fedora (and thus clang) version.
Usually we would expect that such a reformatting brings minor changes.
But this time, the changes are huge. That is mentioned in the release
notes [1] as
Makes PointerAligment: Right working with AlignConsecutiveDeclarations. (Fixes https://llvm.org/PR27353)
[1] https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#clang-format
String properties in libnm's NMSetting really should have NULL as a
default value. The only property that didn't, was "dcb.app-fcoe-mode".
Change the default so that it is also NULL.
Changing a default value is an API change, but in this case probably no
issue. For one, DCB is little used. But also, it's not clear who would
care and notice the change. Also, because previously verify() would reject
a NULL value as invalid. That means, there are no existing, valid profiles
that have this value set to NULL. We just make NULL the default, and
define that it means the same as "fabric".
Note that when we convert integer properties to D-Bus/GVariant, we often
omit the default value. For string properties, they are serialized as
"s" variant type. As such, NULL cannot be expressed as "s" type, so we
represent NULL by omitting the property. That makes especially sense if
the default value is also NULL. Otherwise, it's rather odd. We change
that, and we will now always express non-NULL value on D-Bus and let
NULL be encoded by omitting the property.
