There can also be APs which don't do wpa-psk, but do support
wpa-psk-sha256, so we should match all AKM suites the AP offers to
determine the security type we want to assign it.
According to [1], the only suitable FT cipher suite for WPA3 Enterprise
192-bit mode is "FT over 802.1X, SHA-384", so enable that in case of
key-mgmt is WPA-EAP-SUITE-B-192 to support FT in that case too.
[1] https://mrncciew.com/2020/08/17/wpa3-enterprise/
As mentioned in the wpa_supplicant reference config, when setting PMF to
required with WPA2 (personal or enterprise) authentication, we want to
only enable SHA256 and upwards as HMAC. So enforce that by not passing
WPA-PSK and WPA-EAP to the config in case pmf is set to REQUIRED.
When using modern WPA3 encryption like owe, sae or wpa-eap-suite-b-192
without fallbacks (so not WPA3+WPA2), protected management frames are
required to be enabled by the specification.
For wpa-eap-suite-b-192 we already do this and force PMF to REQUIRED, we
should also do it for OWE and SAE.
Refactor the generation of the key_mgmt option of the wpa_supplicant
config we generate. The goal of this is to lay out all the cases we
support more obviously and to make it a bit clearer that our key-mgmt
property of NMSettingsWirelessSecurity is not the same as the "key_mgmt"
config we set in wpa_supplicant.
wpa-eap-suite-b-192 key-mgmt method uses special values for "pairwise"
and "group" ciphers, we can also handle that a few lines underneath
where those are set to make this a bit easier to read.
We currently set the supplicants PMF config (ieee80211w) inside an if
block that tries to detect whether WPA is used. That if-block doesn't
include the "wpa-eap-suite-b-192" case because we want special
"pairwise" and "group" handling for wpa-eap-suite-b-192. This means
we're currently missing to enable PMF in the "wpa-eap-suite-b-192" case,
even though it's set to REQUIRED.
Fix it by moving the "pairwise" and "group" special-casing down a bit so
we can include "wpa-eap-suite-b-192" in the "Only WPA-specific things
when using WPA" check, that will make sure ieee80211w gets set in the
wpa-eap-suite-b-192 case.
We only set the "ieee80211w" option in the wpa_supplicant config in case
we're using WPA (see the if-block underneath), otherwise the value of
"pmf" is completely ignored. That means the override here (in case WPA
isn't used) isn't getting applied anyway, so just remove it.
It looks a bit weird on the first glance that we do nothing when
NM_SETTING_WIRELESS_SECURITY_PMF_OPTIONAL is used. The reason for this
is that we already intialize the global option "pmf" of wpa_supplicant
to "1" (optional), so add a brief comment about that here.
A connection with key-mgmt=wpa-psk should be able to connect to WPA,
WPA2 and WPA3 APs, choosing the best candidate automatically.
Also pass SAE (WPA3) key-mgmt to wpa_supplicant when it is supported.
For example, I now get this when connecting to a WPA2 network:
<info> [1613749711.2915] Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK SAE FT-SAE'
Before this commit, in AP mode, WPS is started by default and there is no
possibility to disable it. The methods provided as WPS sources seem to
differ from device to device. With some Wifi USB sticks running in AP mode,
the WPS config methods contain "Keypad". Then, I get a pin entry dialog on
Windows machines, even if no pin is configured.
This merge request wires the existing 802-11-wireless-security.wps-method
with wpa_supplicant's configuration to allow disabling WPS.
"libnm-core/" is rather complicated. It provides a static library that
is linked into libnm.so and NetworkManager. It also contains public
headers (like "nm-setting.h") which are part of public libnm API.
Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which
only rely on public API of libnm-core, but are themself static
libraries that can be used by anybody who uses libnm-core. And
"libnm-core/nm-libnm-core-intern" is used by libnm-core itself.
Move "libnm-core/" to "src/". But also split it in different
directories so that they have a clearer purpose.
The goal is to have a flat directory hierarchy. The "src/libnm-core*/"
directories correspond to the different modules (static libraries and set
of headers that we have). We have different kinds of such modules because
of how we combine various code together. The directory layout now reflects
this.
Currently "src/" mostly contains the source code of the daemon.
I say mostly, because that is not true, there are also the device,
settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp
helper, and probably more.
Also we have source code under libnm-core/, libnm/, clients/, and
shared/ directories. That is all confusing.
We should have one "src" directory, that contains subdirectories. Those
subdirectories should contain individual parts (libraries or
applications), that possibly have dependencies on other subdirectories.
There should be a flat hierarchy of directories under src/, which
contains individual modules.
As the name "src/" is already taken, that prevents any sensible
restructuring of the code.
As a first step, move "src/" to "src/core/". This gives space to
reorganize the code better by moving individual components into "src/".
For inspiration, look at systemd's "src/" directory.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/743
