- nm_streq() is easier to read.
- NM_STR_HAS_PREFIX() works only with string literals, and gets
inlined up to one strncmp() call. There is no need to call glib,
to determine strlen(prefix) (that we already know), and then to
call strncmp().
On Fedora/RHEL, the default for main.plugins is "ifcfg-rh". You would
expect that a single configuration file
[main]
plugins-=ifcfg-rh
would result in an empty list of plugins (which subsequently gets
completed with "keyfile").
That didn't happen due to a bug. Fix it.
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.
