As far as NMSupplicantInterface is concerned, don't clamp the
max-scan-ssids to 5. We should track the real value that wpa_supplicant
announces, and it's up to the caller to provide fewer SSIDs.
In particular, we want to limit the number of hidden SSIDs that we
accept from connection profiles, but we don't want to limit the number
of active scans via `nmcli device wifi rescan ssid $SSID [...]`.
(cherry picked from commit c9ae23af5e)
While we request a scan, we are not yet actually scanning. That means, the supplicant's
"scanning" property will only change to TRUE a while after we initiate the scan. It may
even never happen.
We thus need to handle that the request is currently pending and react when the
request completes.
(cherry picked from commit 16c1869476)
Fix the following error when invoking the Connect() p2p method:
call-p2p-connect: failed with Method “fi.w1.wpa_supplicant1.Interface.P2PDevice.Connect” returned type “(s)”, but expected “()”
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling')
(cherry picked from commit a5338affb5)
In NMSupplicantInterface, we determine whether we currently are scanning
both on the "scanning" supplicant state and the "Scanning" property.
Extend that. If we currently are scanning and are about to clear the
scanning state, then pretend to still scan as long as we are still
initializing BSS instances. What otherwise happens is that we declare
that we finished scanning, but the NMWifiAP instances are not yet ready.
The result is, that `nmcli device wifi` will already start printing the
scan list, when we didn't yet fully process all access points.
Now, _notify_maybe_scanning() will delay switching the scanning state to
disabled, as long as we have BSS initializing (bss_initializing_lst_head).
Also, ignore the "ScanDone" signal. It's redundant to the "Scanning"
property anyway.
Also, only set priv->last_scan_msec when we switch the scanning state
off. That is the right (and only) place where the last-scan timestamp
needs updating.
Certain properties (for example "scanning") are combined from multiple
other properties. So, we want to notify a changed signal, exactly when
something relevant changes. We also may not want to emit a signal while
we are still in the middle of changing multiple properties together.
Only at certain places we want to check and emit the signal.
Simplify the implementation for that by tracking the property value that
we currently expose, and keeping state about when it changes.
g_clear_pointer() would always cast the destroy notify function
pointer to GDestroyNotify. That means, it lost some type safety, like
GPtrArray *ptr_arr = ...
g_clear_pointer (&ptr_arr, g_array_unref);
Since glib 2.58 ([1]), g_clear_pointer() is also more type safe. But
this is not used by NetworkManager, because we don't set
GLIB_VERSION_MIN_REQUIRED to 2.58.
[1] f9a9902aac
We have nm_clear_pointer() to avoid this issue for a long time (pre
1.12.0). Possibly we should redefine in our source tree g_clear_pointer()
as nm_clear_pointer(). However, I don't like to patch glib functions
with our own variant. Arguably, we do patch g_clear_error() in
such a manner. But there the point is to make the function inlinable.
Also, nm_clear_pointer() returns a boolean that indicates whether
anything was cleared. That is sometimes useful. I think we should
just consistently use nm_clear_pointer() instead, which does always
the preferable thing.
Replace:
sed 's/\<g_clear_pointer *(\([^;]*\), *\([a-z_A-Z0-9]\+\) *)/nm_clear_pointer (\1, \2)/g' $(git grep -l g_clear_pointer) -i
Move local variables to inner scope.
Also, drop code comment that doesn't give additional information
beyond what is already plainly visible in source code.
This pull requests sets the OWE flag for an open network advertising an
OWE enabled transition BSSID. This way, hostapd will automatically
connect to the OWE secured BSSID advertised in the transition mode
information element.
Signed-off-by: David Bauer <mail@david-bauer.net>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/442
When we receive a "InterfaceRemoved" signal, we will end up calling
set_state_down(). That emits a "state" change signal, which causes
NMDeviceWifi to unref the supplicant interface. This may already
give up the last reference, and we cleanup the supplicant state
(by again calling set_state_down()). When we return, set_state_down()
will crash because it operates on an already destroyed instance.
Avoid that by keeping a reference to the interface during set_state_down().
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling')
https://bugzilla.redhat.com/show_bug.cgi?id=1815058
For many purposes, the supplicant features are not very interesting (as
they are also mostly static for a certain release/distribution). Combine
the multiple logging lines into one.
Also, sort the NMSupplCapType enum values consistently with the order
in which we log them.
Also, rename the logging output for features to match the enum name.
E.g. "FAST" instead of "EAP-FAST".
Now:
> supplicant: supported features: AP+ PMF+ FILS- P2P+ FT+ SHA384+ MESH+ FAST+ WFD+
Avoid GDBusProxy, instead use GDBusConnection directly. I very much
prefer this because that way we have explicit control over what happens
on D-Bus. With GDBusProxy this is hidden under another layer of complex
code. The hardest part when using a D-Bus interface is to manage the
state via an asynchronous medium. GDBusProxy contains state about the
D-Bus interface and duplicate the state that we track. This makes it hard
to reason about things.
Rework creation of NMSupplicantInterface. Previously, a NMSupplicantInterface
had multiple initialization states. In particular, the first state would not
yet tie the interface to a certain D-Bus object path. Instead, NMSupplicantInterface
would try and retry to create the D-Bus object.
Now, NMSupplicantManager has an asynchronous method to create interface
instances. The manager only creates an interface instance after the D-Bus
path is known. That means, a NMSupplicantInterface instance is now
strongly tied to a name-owner and D-Bus path.
It follows that the state of NMSupplicantInterface can only go from STARTING,
via the supplicant states, to DOWN. Never back. That was already previously
the case that the state from DOWN was final and once the 3 initial
states were passed, the interface's state would never go back to the initial
state. Now this is more strict and more formalized. The 3 initialization states
are combined.
I think the tighter state handling simplifies users of NMSupplicantInterface.
See for example "nm-device-ethernet.c". It's still complicated, because handling
state is fundamentally difficult.
NMSupplicantManager will take care to D-Bus activate wpa_supplicant only
when necessary (poke). Previously, creating the manager instance
would always start suppliant service. Now, it's started on demand.
It's very unlikely that we have actual blobs for a Wi-Fi network.
That is because the settings plugins (keyfile, ifcfg-rh) convert
blobs to files on disk when writing the profile. So, you can only
have them by editing the files directly to contain blobs.
At that point, don't always create the GHashTable for blobs.
The _GET_PRIVATE() macros are all implemented based on
_NM_GET_PRIVATE(). That macro tries to be more type safe and uses
_Generic() to do the right thing. Explicitly casting is not only
unnecessary, it defeats these (static) type checks.
Don't do that.
Several macros are used to define function. They had a "_STATIC" variant,
to define the function as static.
I think those macros should not try to abstract entirely what they do.
They should not accept the function scope as argument (or have two
variants per scope). This also because it might make sense to add
additional __attribute__(()) to the function. That only works, if
the macro does not pretend to *not* define a plain function.
Instead, embrace what the function does and let the users place the
function scope as they see fit.
This also follows what is already done with
static NM_CACHED_QUARK_FCN ("autoconnect-root", autoconnect_root_quark)
We frequently have code that converts a string to number/enum.
Use a preferred implementation via the NM_UTILS_STRING_TABLE_LOOKUP_DEFINE()
macro.
Also, this does binary search, so in most cases it's (slightly) faster.
Defines in our header files should all have an NM specific prefix.
Rename.
Also rename the related defines in the source file. Usually declarations
in a source file should not have an NM prefix. But here they have for
consistency.
We keep adding capabilities. Tracking them individually via boolean (or
ternary) properties is cumbersome.
Instead, use an enum NMSupplCapType and a corresponding bitmask
NMSupplCapMask. The latter can track whether a capability is detected,
detected to be absent or not detected (unknown).
We should handle features/capabilities more generically.
Add an enum type for that. It will be used next.
Also, wpa_supplicant calls this "Capabilities", not features.
Use that name.
The signal is unused (and should be removed).
Still, the parameter passed to g_signal_emit() is a C string, not a
GVariant. I think as there are no subscribers, glib wouldn't actually
do anything with the arguments. Though, I am not sure whether glib still
tries to initialize a GValue with a GVariant type, leading to a crash.
Fixes: f05b7a78c9 ('supplicant: Track P2P Group information, creation and destruction')
Move it to shared as it's useful for clients as well.
Move and rename nm_dbus_manager_new_auth_subject_from_context() and
nm_dbus_manager_new_auth_subject_from_message() in nm-dbus-manager.c
as they're needed there.
The abbreviations "ns" and "ms" seem not very clear to me. Spell them
out to nsec/msec. Also, in parts we already used the longer abbreviations,
so it wasn't consistent.
PMF can be used with SAE, allow it. Actually, it is required according
to WPA3 specifications but there are implementations that don't
require it (hostapd can be configured in a such way); so let's not
make it mandatory for WPA3.
Fixes: 6640fb4b36 ('supplicant: add support for SAE key management')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/257
The targets that involve the use of the `NetworkManager` library,
built in the `src` build file have been improved by applying a set
of changes:
- Indentation has been fixed.
- Set of objects used in targets have been grouped together.
- Aritificial dependencies used to group dependencies and custom
compiler flags have been removed and their use replaced with
proper dependencies and compiler flags to avoid any confussion.
