lgtm.com warns:
int nm_owned:3;
>> Bit field nm_owned of type int should have explicitly unsigned integral, explicitly signed integral, or enumeration type.
So make it a NMTernary instead. It's nicer anyway.
lgtm.com flags this. The check was there to be better safe than sorry.
Also, it seems better to have code that shows what happens instead
of a verbose code comment (or no comment at all). Anyway, avoid the
false positive.
Reported by coverity:
>>> CID 210222: Null pointer dereferences (NULL_RETURNS)
>>> Dereferencing a pointer that might be "NULL" "f" when calling
"fseek".
Fixes: ac5206aa9c ('2007-11-21')
If the driver is unknown, that doesn't necessarily mean that the match
passes. Instead, the match passes if there is no positive match that
asks for the driver name.
%NULL means that the string is unknown. The pattern should still match
if there are no positive matches that want to match against the string.
For example, the nm_device_get_driver() might return NULL. If we have
a match.driver setting, we still need to handle that somehow that it
makes sense.
- write_match_setting() never fails. Don't let it return a boolean
error result.
- drop "if (!name || !name[0])" checks. It's not possibly to configure
a name %NULL in NMSettingMatch (without triggering assertions). Also,
an empty name "" is not valid, so we wouldn't expect it. There is one
problem with the way how we concatenate the string list: it uses
spaces as separator, while stripping spaces. That means, in the
currenty format, an empty token "" cannot be expressed. On the other
hand, serializing it would lead to duplicate spaces, that get dropped
during re-read. So the empty name wasn't valid from the start, but it
also cannot be encoded.
- use nm_gstring_add_space_delimiter() and nm_gstring_prepare().
Add a new "driver" match option to nm-settings. It allows to disable a
network connection configuration if a pattern is found or is not found
in the device driver name.
Add a new "kernel-command-line" match option to nm-settings. It allows
to disable a network connection configuration if a pattern is found or
is not found in /proc/cmdline.
This warning is from coverity against 1.18.6. But it applies
in a similar manner here.
1. NetworkManager-1.18.6/src/devices/nm-device-macsec.c:811:25: warning: Value stored to 'priv' during its initialization is never read
# NMDeviceMacsecPrivate *priv = NM_DEVICE_MACSEC_GET_PRIVATE (self);
# ^~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4. NetworkManager-1.18.6/src/devices/nm-device-macsec.c:811:25: note: Value stored to 'priv' during its initialization is never read
# NMDeviceMacsecPrivate *priv = NM_DEVICE_MACSEC_GET_PRIVATE (self);
# ^~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 809| {
# 810| NMDeviceMacsec *self = NM_DEVICE_MACSEC (object);
# 811|-> NMDeviceMacsecPrivate *priv = NM_DEVICE_MACSEC_GET_PRIVATE (self);
# 812|
# 813| macsec_secrets_cancel (self);
Also, silently ignore all environment variables with a name that
is not valid UTF-8. We would hit an assertion trying to put that
in a GVariant (or sending it via D-Bus).
Only _scan_request_ssids_track() adds elements to the list, and that already
trims the list to a maxium length. In all other cases, we never expect a need
to trim the list.
We make decisions based on the timestamp. We should only fetch the timestamp
once, and make consistent decisions about that. Don't read different timestamps.
While we are not activated, there is less need to rate limit the scan
requests to 8 seconds. Only rate limit the requests for 1.5 seconds
in that case.
Also, when changing the MAC address, supplicant flushes the AP list.
We should be able to scan right away. Reset the counters for the rate
limiting and periodic scanning.
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 [...]`.
Handling the scanning is complicated.
- we want to have periodic scans. But only at certain times,
and with an increasing back off timeout.
- the user can initiate explicit scans via D-Bus. Thereby a list
of SSIDs scan be provided.
- if there are any hidden Wi-Fi profiles configured, we want
to explicitly scan for their SSIDs.
- explicit scans are not possible at any time. But we should not reject
the scan request, but instead remember to scan later, when possible.
This is a heavy rework. It also aims to fix issues of scanning since
the recent rework of supplicant handling in commit b83f07916a
('supplicant: large rework of wpa_supplicant handling') that can render
Wi-Fi scanning broken.
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling'):
The Station.ConnectHiddenNetwork will provision a network in the iwd
known-networks list. This should allow us to later use the
Network.Connect interface to connect in the future.
(Note: Attempts to use Station.ConnectHiddenNetwork on already provisioned
networks, i.e. networks iwd knows about, will fail.)
This commit squashed several fixups made by thaller.
Newer versions of iwd has supported connecting to hidden networks for a
while now. There's a separate "connect-hidden" command in iwctl that
needs to be used instead of the regular "connect" command.
The equivalent on dbus is to use ConnectHiddenNetwork instead of
Connect on the Station interface. NetworkManager however uses the
Network interface and given we the explicit SSID usage we can connect
to hidden networks with that.
This change disabled the explicit check that disallows even attempting
hidden networks when using iwd.
This has been tested to work with a previously known hidden network.
Tests connecting to a previously unknown network has failed.
GObject signals only complicate the code and are less efficient.
Also, NM_DEVICE_AUTH_REQUEST signal really invoked an asynchronous
request. Of course, fundamentally emitting a signal *is* the same as
calling a method. However, implementing this as signal is really not
nice nor best practice. For one, there is a (negligible) overhead emitting
a GObject signal. But what is worse, GObject signals are not as strongly
typed and make it harder to understand what happens.
The signal had the appearance of providing some special decoupling of
NMDevice and NMManager. Of course, in practice, they were not more
decoupled (both forms are the same in nature), but it was harder to
understand how they work together.
Add and call a method nm_manager_device_auth_request() instead. This
has the notion of invoking an asynchronous method. Also, never invoke
the callback synchronously and provide a cancellable. Like every asynchronous
operation, it *must* be cancellable, and callers should make sure to
provide a mechanism to abort.
It's about as complicated to track a CList as it is to track
an allocated array. The latter requires fewer allocations and
has better locality. That makes it preferable.
We want that our asynchronous operations are cancellable.
In fact, NMAuthChain is already (manually) cancellable by the
user calling nm_auth_chain_destroy(). However, sometimes we have a
GCancellable at hand, so the callers would have to register to the
cancellable themselves.
Instead, support setting a cancellable to the NMAuthChain, that aborts
the request and invokes the callback.
It does so always on an idle handler. Also, the user may only set the
cancellable once, and only before starting the first call.
NMDevice already has access to the NMSettings singleton. It is permissible that
NMDevice *knows* about NMManager. The current alternative is emitting GObject signals
like NM_DEVICE_AUTH_REQUEST, pretending that NMDevice and NMManager would be completely
independent, or that there could be anybody else handling the request aside NMManager.
No, NMManager and NMDevice may know each other and refer to each other. Just like
NMDevice also knows and refers to NMSettings.
Conceptionally, the MUD URL really depends on the device, and not so
much the connection profile. That is, when you have a specific IoT
device, then this device probably should use the same MUD URL for all
profiles (at least by default).
We already have a mechanism for that: global connection defaults. Use
that. This allows a vendor drop pre-install a file
"/usr/lib/NetworkManager/conf.d/10-mud-url.conf" with
[connection-10-mud-url]
connection.mud-url=https://example.com
Note that we introduce the special "connection.mud-url" value "none", to
indicate not to use a MUD URL (but also not to consult the global connection
default).
