Add a new key management option to support WPA3 Enteprise wifi
connection.
Only supported with wpa_supplicant for the time being.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
Currently libnm headers include <linux/if_{ether,infiniband,vlan}.h>.
These are public headers, that means we drag in the linux header to all
users of <NetworkManager.h>.
Often the linux headers work badly together with certain headers from libc.
Depending on the libc version, you have to order linux headers in the right
order with respect to libc headers.
We should do better about libnm headers. As a first step, assume that
the linux headers don't get included by libnm, and explicitly include
them where they are needed.
When activating a connection using nmtui, veth connections where not
being listed. This patches fixes this and they are now being listed.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
<netinet/ether.h> with musl defines ethhdr struct, which conflicts
with <linux/if_ether.h>. The latter is included by "nm-utils.h",
so this is a problem.
Drop includes of "netinet/ether.h" that are not necessary.
If we call g_cancellable_connect() on a GCancellable that is already
cancelled, then the callback is invoked synchronously. We need to
handle that.
However, we can slightly simplify the code. There is no change in
behavior, but we can always let the cancelled callback return the
result.
"iface_data->cancellable" is an internal cancellable for the parallel
HTTP requests. Once we encounter a failure, those requests are all
obsolete and must be cancelled.
There are two GCancellable at work: one is provided by the user
during nmcs_provider_get_config(), and one is used internally for the
individual HTTP GET requests.
In _get_config_fetch_done_cb(), if the error reason is "cancelled",
then it means that our internal iface_data->cancellable was cancelled.
Probably because an error happend (like a timeout or the user cancelled
the external GCancellable).
In that case, we must not report that the task completed with a
cancellation, because we need to preserve the error that was the
original cause.
NetworkManager is now able to configure veth interfaces throught the
NMSettingVeth. Veth interfaces only have "peer" property.
In order to support Veth interfaces in NetworkManager the design need
to pass the following requirements:
* Veth setting only has "peer" attribute.
* Ethernet profiles must be applicable to Veth interfaces.
* When creating a veth interface, the peer will be managed by
NetworkManager but will not have a profile.
* Veth connection can reapply only if the peer has not been modified.
* In order to modify the veth peer, NetworkManager must deactivate the
connection and create a new one with peer modified.
In general, it should support the basis of veth interfaces but without
breaking any existing feature or use case. The users that are using veth
interfaces as ethernet should not notice anything changed unless they
specified the veth peer setting.
Creating a Veth interface in NetworkManager is useful even without the
support for namespaces for some use cases, e.g "connecting one side of
the veth to an OVS bridge and the other side to a Linux bridge" this is
done when using OVN kubernetes [1][2]. In addition, it would provide
persistent configuration and rollback support for Veth interfaces.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1885605
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1894139
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
Revert this change. One problem is that none of the current GUIs
(nm-connection-editor, gnome-control-center, plasma-nm) expose the
dns-priority option. So, users tend to have their profile value set to
0. Changing the default means for them not only a change in behavior,
but its hard to fix via the GUI.
Also, what other call DNS leaks, is Split DNS to some. Both uses make
sense, but have conflicting goals. The default cannot accommodate both
at the same time.
Also, with split DNS enabled (dnsmasq, systemd-resolved), the concern
for DNS leaks is smaller. Imagine:
Wi-Fi profile with ipv4.dns-priority (effectively) 100, domain "example.com".
VPN profile with ipv4.dns-priority (effectively) 50 and a default route.
That is a common setup that one gets by default (and what probably many
users have today). In such a case with split DNS enabled, the Wi-Fi's DNS
server only sees requests for "*.example.com". So, it does not leak
everything.
Hence, revert this change before 1.28.0 release to the earlier behavior.
This reverts commit af13081bec.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/688
The if-else-if constuct spans many lines and it is not easy to see that
there is no common action after the if-else-if construct.
Instead, at the end of each if-block, just "continue" the loop. This
is similar to a "return-early" apprach and it mean you don't need
to think what happens at the end of the if-block.
Removing a setting that is not present should not be an error. The user
asked that the profile doesn't have the requested setting, and that
should succeed (even if that results in no actual change).
Consider when you want to make a hotspot profile "open". That implies
to remove the "wifi-sec" and "802-1x" settings. But you may
not check before whether the profile is already open, and whether
it already has those settings. We should just allow
$ nmcli connection modify "$PROFILE" remove wifi-sec remove 802-1x
to succeed, regardless whether this changes anything or not.
Likewise, if you do
$ nmcli connection modify "$PROFILE" con-name foo
$ nmcli connection modify "$PROFILE" con-name foo
then the second command doesn't fail with "the name is
already \"foo\"". It just succeeds.
nmcli --complete-args connection add type ''
would not show "ovs-{dpdk,patch}", because the conditions about what
makes a base type are not consistent with what NMSettingConnection's
verify() does.
Fix that.
We can generate "generate-docs-nm-settings-nmcli.xml" by running "clients/cli/generate-docs-nm-settings-nmcli".
However, during cross compilation, that binary gets build in the target architecture,
it can thus not run to generate the XML.
Note that "--enable-gtk-doc" requires "--enable-introspection".
For generating "settings-docs.h" we (only) need introspection/pygobject.
We also have a pre-generated .in file that we can use if introspection
is not available. Since we have a pre-generated variant, it would be fine
to always use that one. However, we want to use generate the file if we
have the necessary dependencies, because thereby we can check whether
the pre-generated file is identical to what would be generated.
We have a similar problem with "generate-docs-nm-settings-nmcli.xml".
However there we don't need introspection, but merely being able to
execute a binary that we build. That does not work during cross
compilation, so we will honor "--enable-gtk-doc" flag to decide when
to generate the file.
For consistency, also adjust the condition for "settings-docs.h" to only
generate the file if we have "--enable-gtk-doc" (but not it we build
with "--enable-introspection" alone).
Add reason for device state change.
Add dbus test method to force failure of activation, set the
device state and the active connection state.
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
For historic reasons is NMSettingBond implemented differently from other
settings. It uses a strdict, and adds some validation on top of that.
The idea was probably to be able to treat bond options more generically.
But in practice we cannot treat them as opaque values, but need to know,
validate and understand all the options. Thus, this implementation with a
strdict is not nice.
The user can set the GObject property NM_SETTING_BOND_OPTIONS to any
strdict, and the setter performs no validation or normalization. That
is probably good, because g_object_set() cannot return an error to
signalize invalid settings. As often, we have corresponding C API like
nm_setting_bond_add_option() and nm_setting_bond_remove_option(). It
should be possible to get the same result both with the C API and with
the GObject property setting. Since there is already a way to set
certain invalid values, it does not help if the C API tries to prevent
that. That implies, that also add-option does not perform additional
validation and sets whatever the user asks.
Remove all validation from nm_setting_bond_add_option() and
nm_setting_bond_remove_option(). This validation was anyway only very
basic. It was calling nm_setting_bond_validate_option(), which can check
whether the string is (for example) and integer, but it cannot do
validation beyond one option. In most cases, the validation needs to
take into account the bond mode or other options, so validating one
option in isolation is not very useful.
Proper validation should instead be done via nm_connection_verify().
However, due to another historic oddity, that verification is very
forgiving too and doesn't reject many invalid settings when it should.
That is hard to fix, because making validation more strict can break
existing (and working) configurations. However, verify() already contains
basic validation via nm_setting_bond_validate_option(). So in the previous
behavior nm_setting_bond_add_option() would silently do nothing (only
returning %FALSE) for invalid options, while now it would add the
invalid options to the dictionary -- only to have it later fail validation
during nm_connection_verify(). That is a slight change in behavior, however it
seems preferable.
It seems preferable and acceptable because most users that call
nm_setting_bond_add_option() already understand the meaning and valid
values. Keyfile and ifcfg-rh readers are the few exceptions, which really just
parse a string dictionary, without need to understand them. But nmtui
or nmstate already know the option they want to set. They don't expect
a failure there, nor do they need the validation.
Note that this change in behavior could be dangerous for example for the
keyfile/ifcfg-rh readers, which silently ignored errors before. We
don't want them to start failing if they read invalid options from a
file, so instead let those callers explicitly pre-validate the value
and log an warning.
https://bugzilla.redhat.com/show_bug.cgi?id=1887523
Change the default DNS priority of VPNs to -50, to avoid leaking
queries out of full-tunnel VPNs.
This is a change in behavior. In particular:
- when using dns=default (i.e. no split-dns) before this patch both
VPN and the local name server were added (in this order) to
resolv.conf; the result was that depending on resolv.conf options
and resolver implementation, the name servers were tried in a
certain manner which does not prevent DNS leaks.
With this change, only the VPN name server is added to resolv.conf.
- When using a split-dns plugin (systemd-resolved or dnsmasq), before
this patch the full-tunnel VPN would get all queries except those
ending in a local domain, that would instead be directed to the
local server.
After this patch, the VPN gets all queries.
To revert to the old behavior, set the DNS priority to 50 in the
connection profile.
With "connection.multi-connect", a profile can be activated multiple
times on a device with `nmcli connection show`. Also, a profile may be
in the process of deactivating on one device, while activating on
another one. So, in general it's possible that `nmcli connection show`
lists the same profile on multiple lines (reflecting their multiple
activation states).
If the user requests no fields that are part of the activation state,
then the active connections are ignored. For example with `nmcli
-f UUID,NAME connection show`. In that case, each profile is listed only
once.
On the other hand, with `nmcli -g UUID,NAME,DEVICE connection show` the
user again requested also to see the activation state, and a profile can
appear multiple times.
To handle that, we need to consider which fields were requested.
There was a bug where the "ACTIVE" field was not treated as part of the
activation state. That results in `nmcli -f UUID,NAME,ACTIVE connection
show` always returning "no". Fix that.
Fixes: a1b25a47b0 ('cli: rework printing of `nmcli connection` for multiple active connections')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/547https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/642
Previously, both nm_setting_connection_add_permission() and the GObject
property setter would merely assert that the provided values are valid
(and otherwise don't do anything). That is bad for handling errors.
For example, we use the property setter to initialize the setting from
keyfile and GVariant (D-Bus). That means, if a user provides an invalid
permissions value, we would emit a g_critical() assertion failure, but
otherwise ignore the configuration. What we instead need to do is to
accept the value, and afterwards fail verification. That way, a proper error
message can be generated.
$ mcli connection add type ethernet autoconnect no ifname bogus con-name x connection.permissions 'bogus:'
(process:429514): libnm-CRITICAL **: 12:12:00.359: permission_new: assertion 'strchr (uname, ':') == NULL' failed
(process:429514): libnm-CRITICAL **: 12:12:00.359: nm_setting_connection_add_permission: assertion 'p != NULL' failed
Connection 'x' (2802d117-f84e-44d9-925b-bfe26fd85da1) successfully added.
$ $ nmcli -f connection.permissions connection show x
connection.permissions: --
While at it, also don't track the permissions in a GSList. Tracking one
permission in a GSList requires 3 allocations (one for the user string,
one for the Permission struct, and one for the GSList struct). Instead,
use a GArray. That is still not great, because GArray cannot be embedded
inside NMSettingConnectionPrivate, so tracking one permission also
requires 3 allocations (which is really a fault of GArray). So, GArray
is not better in the common case where there is only one permissions. But even
in the worst case (only one entry), GArray is no worse than GSList.
Also change the API of nm_setting_connection_add_permission().
Previously, the function would assert that the arguments are in
a certain form (strcmp (ptype, "user") == 0), but still document
the such behaviors like regular operation ("[returns] %FALSE if @ptype
or @pitem was invalid"). Don't assert against the function arguments.
Also, if you first set the user to "fo:o", then
nm_setting_connection_add_permission() would accept it -- only at
a later phase, the property setter would assert against such values.
Also, the function would return %FALSE both if the input value was
invalid (an error) and if the value already existed. I think the
function should not treat a duplicate entry like a badly formatted
input.
Now the function does much less asserting of the arguments, but will
return %FALSE only if the values are invalid. And it will silently ignore
duplicate entries.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/636
Run:
./contrib/scripts/nm-code-format.sh -i
./contrib/scripts/nm-code-format.sh -i
Yes, it needs to run twice because the first run doesn't yet produce the
final result.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
clang-format will re-format this in multiple lines, use C comment
to not break compilation after applying code-style with clang-format.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
nm_utils_hexstr2bin_full() is our general hexstr to binary parsing
method. It uses (either mandatory or optional) delimiters. Before,
if delimiters are in use, it would accept individual hexdigits.
E.g. "a:b" would be accepted as "0a:0b:.
Add an argument that prevents accepting such single digits.
"active_slave" option is a deprecated alias for "primary". nmtui can configure
the "primary" option, so whenever it configures a profile the "active_slave"
option should be unset.
"active_slave" is by now deprecated and became an alias for "primary".
If a profile specifies both properties, only "primary" is honored, without
failing validation (to not break existing behavior).
Maybe we should introduce a normalization for such cases. But normalize
might not do the right thing, if a profile currently has "primary" set,
and the user modifies it to set "active_slave" to a different value,
normalize would not know which setting was set first and remove
"active_slave" again.
In the past, nm_setting_bond_add_option() performed some simple
normalization, but this was dropped, because (such incompatible) settings
can also be created via the GObject property. Our C accessor function
should not be less flexible than other ways of creating a profile.
In the end, whenever a user (or a tool) creates a profile, the tool must
be aware of the semantics. E.g. setting an IP route without a suitable
IP address is unlike to make sense, the tool must understand what it's
doing. The same is true for the bond options. When a tool (or user) sets
the "active_slave" property, then it must clear out the redundant
information from the "primary" setting. There is no alternative to this
problem than having tools smart enough to understand what they are
doing.
WireGuard's wg-quick primarily wants to avoid DNS leaks, and thus also
our import code should generate profiles that configure exclusive DNS
servers. This is done by setting "ipv[46].dns-priority" to a negative
value.
Note that if a profile leaves the DNS priority at zero (which in many
regard is the default), then the zero translates to 50 (for VPN
profiles) and 100 (for other profiles).
Instead of setting the DNS priority to -10, set it to -50. This gives
some more room so that the user can choose priorities that are worse
than the WireGuard's one, but still negative (exclusive). Also, since
the positive range defaults to 50 and 100, let's stretch the range a
bit.
Since this only affects import and creation of new profiles, such a
change in behavior seems acceptable.
