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.
<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.
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.
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.
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>
Use a macro that uses NM_CAST_STRV_CC() to cast the strv argument. Note that
NM_CAST_STRV_CC() uses C11's _Generic() to check whether the argument is
of a valid type.
Without this, `nmcli device modify "$DEVICE"` leads to a crash. At least
since commit c5d45848dd ('cli: mark argv argument for command line
parsing as const'), when this happens.
That is, because it passes a NULL strv array with argc being set to
zero. nmc_process_connection_properties() is not supposed to access
the array, if there are no elements there.
Fixes: c5d45848dd ('cli: mark argv argument for command line parsing as const')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/492
Before 1.24, nm_setting_bond_add_option() would clear
miimon/arp_interval settings when the respective other was set.
That was no longer done, with the effect that enabling (for example)
miimon on a bond profile that has arp_interval enabled, sets both
conflicting options.
That is not a severe problem, because the profile still validates.
However, at runtime only one of the settings can be actually configured.
Fix that, by restoring the previous behavior for the client. But note
that this time it's implemented in the client, and not in libnm's
nm_setting_bond_add_option().
$ nmcli -f GENERAL.HWADDR device show ovsport0
GENERAL.HWADDR: (unknown)
but:
$ nmcli -f GENERAL.HWADDR --terse device show ovsport0
GENERAL.HWADDR:
This is an API change of nmcli.
The connection is automatically unreferenced when the function
returns.
Fixes: 9c5ea0917d ('devices: reuse the hotspot connection if we find appropriate one'):
We have the correct meta-data of supported properties for nmcli. It is
in clients/common. Use that for generating the manual page instead of
the properties that are part of libnm (some properties may be in libnm
but not supported by nmcli, or some properties may not be GObject
properties, and not detected as by GObject introspection).
Commit 37e7fa38c2 ("nm-supplicant-interface: enable OWE security
when transition mode is available") adds the OWE security flag in
case a valid OWE transtition mode IE is present on the beacon.
It also removes the OWE security flag in case the Iinformation elements
of a beacon are updated and a OWE transition mode IE can't be found.
When a pure OWE AP updates it's Information Elements (e.g. BSS Load
Element), the OWE security flag is falsely removed.
Introduce a new NM_802_11_AP_SEC_KEY_MGMT_OWE_TM security flag and use
it exclusively for OWE transition mode. Don't use the
M_802_11_AP_SEC_KEY_MGMT_OWE security flag on transition-mode APs.
Signed-off-by: David Bauer <mail@david-bauer.net>
