Update the list of Wi-Fi channels in the 5GHz band:
- remove channels 7–16, which were part of 802.11j but were revoked
in 2017;
- remove the entries that are not valid as primary 20MHz channels but
only as the center of bonded channels, e.g. 38, 42, etc.
- add channel 144, introduced in the 802.11ac standard
Also restrict list of default channels for a 5GHz hotspot to those
that are available everywhere and without DFS.
Clients typically want to show the band of an AP. The information is
already available because we export the frequency, but it is necessary
to implement some conversion logic.
Export libnm symbol nm_utils_wifi_freq_to_band() to do
that. Previously the function was used internally to generate the
value of the "band" string property from the frequency. For a public
function it is clearer if we return a enum value.
Until now the Wi-Fi bands were named after the first 802.11 standard
that introduced them: "a" for 5GHz introduced in 802.11a and "bg" for
2.4GHz introduced in 802.11b/g. With new bands added, this naming
scheme doesn't sound very intuitive to remember for users. Furthermore
we have now 6GHz that is introduced by 802.11ax (Wi-Fi 6), but the
compatible devices can use all three the bands (2.4, 5, 6 GHz).
For the 6 GHz band, simply name it "6GHz".
Co-authored-by: Beniamino Galvani <bgalvani@redhat.com>
The formula is wrong for channels above 144 because the layout of the
80MHz channels is not regular. Use a lookup table.
Fixes: 7bb5961779 ('supplicant: honor the 'wifi.channel-width' property in AP mode')
The powersave setting was apparently not touched at all in the iwd device,
so this adds the configuration, analogous to how the wifi device does.
Fixes#1750
The purpose of the validation is to check that we pass to the
supplicant a configuration that it can understand. For certificates
and keys we enforce a maximum length of 64KiB; that means that the
value of the property we send (i.e. the file path or the blob id) can
be at most 64KiB. Instead we wrongly checked the size of the blob
data.
Fix the validation. Also, enforce a maximum blob size of 32MiB.
Fixes: e85cc46d0b ('core: pass certificates as blobs to supplicant for private connections')
Currently NetworkManager depends on the external ping binary to
perform the reachability check on IP addresses. This means that the NM
daemon package must depend on another package. On Fedora the iputils
package is 800KiB.
Implement the same functionality natively so that we can drop such
dependency.
Introduce a function that pings a given host. It opens a "ping socket"
(IPPROTO_ICMP), binds it to the given ifindex, connects it to the
remote address, and keep sending ICMP echo-request packets until it
receives a reply or the optional timeout is reached. By using this
kind of socket, the kernel automatically sets the ICMP ID on outgoing
packets and matches incoming packets by the same ID.
Only allow private VPN connections if the VPN plugin declares the
supports-safe-private-file-access capability. Also check that the
private connection doesn't have more than one owner.
If we add a new property in the future and it references a certificate
or key stored on disk, we need to also implement the logic to verify
the access to the file for private connections.
Add a new property flag NM_SETTING_PARAM_CERT_KEY_FILE to existing
certificate and key properties, so that it's easier to see that they
need special treatment. Also add some assertions to verify that the
properties with the flag are handled properly.
While at it, move the enumeration of private-files to the settings.
In case of private connections, the device has already read the
certificates and keys content from disk, validating that the owner of
the connection has access to them. Pass those files as blobs to the
supplicant so that it doesn't have to read them again from the
filesystem, creating the opportunity for TOCTOU bugs.
During stage2 (prepare) of an activation, check if the connection is
private and if it contains any certificate/key path. If so, start
reading the files and delay stage2. Once done, store the files'
content into priv->private_files.table and continue the activation.
Add function nm_utils_read_private_files(). It can be used to read a
list of paths as the given user. It spawns the daemon-helper to read
each path and returns asynchronously a hash table containing the files
content.
Also add nm_utils_get_connection_private_files_paths() to return a
list of file paths referenced in a connection. The function currently
returns only 802.1x file paths for certificates and keys.
The full output of the daemon helper is added to a NMStrBuf, without
interpreting it as a string (that is, without stopping at the first
NUL character).
However, when we retrieve the content from the NMStrBuf we assume it's
a string. This is fine for certain commands that expect a string
output, but it's not for other commands as the read-file-as-user one.
Add a new argument to nm_utils_spawn_helper() to specify whether the
output is binary or not. Also have different finish functions
depending on the return type.
When connecting, we add the blobs to the Interface object of the
supplicant. Those blobs are not removed on disconnect and so when we
try to add blobs with the same id, the supplicant returns an error.
Make sure we start from a clean slate on each connection attempt, by
deleting all existing blobs. Probably we should also delete the added
blobs on disconnect, but that's left for a future improvement.
`use_carrier` is removed from kernel since 6.18 [1], and returns
the following error if set to 0:
> option obsolete, use_carrier cannot be disabled
This causes a failure of test-link-linux, so let's set it to 1.
[1] https://lore.kernel.org/all/2029487.1756512517@famine/
We write into the buffer returned by nm_strsplit_set_full(), even
though it is returned as `const char**`. The function description
claims this is fine:
> * It is however safe and allowed to modify the individual strings in-place,
> * like "g_strstrip((char *) iter[0])".
Remove the const qualifier via cast so that it does not raise errors.
We reallocate this value in the function, which is necessary
because we write into it, and the input is const.
Move the allocation into a local variable instead of overwriting
the input pointer, because we are also pointing to it via
`char* s`, which is not const.
Restrict connectivity check DNS lookups to just the relevant link if the link
has a per-link DNS resolver configured. This change was previously discussed as
part of issue
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1836, and
brings NM's behavior back in line with the behavior documented in the man page.
The connectivity check checks for a per-link DNS resolver by querying
systemd-resolved's `ScopeMask` for the link; this involves a small D-Bus
roundtrip, but is ultimately the more flexible solution since it is also capable
of dealing with per-link DNS configuration stemming from other sources.
Fixes: e6dac4f0b6 ('core: don't restrict DNS interface when performing connectivity check')
This new endpoint type has been recently added to the kernel in v6.18
[1]. It will be used to create new subflows from the associated address
to additional addresses announced by the other peer. This will be done
if allowed by the MPTCP limits, and if the associated address is not
already being used by another subflow from the same MPTCP connection.
Note that the fullmesh flag takes precedence over the laminar one.
Without any of these two flags, the path-manager will create new
subflows to additional addresses announced by the other peer by
selecting the source address from the routing tables, which is harder to
configure if the announced address is not known in advance.
The support of the new flag is easy: simply by declaring a new flag for
NM, and adding it in the related helpers and existing checks looking at
the different MPTCP endpoint. The documentation now references the new
endpoint type.
Note that only the new 'define' has been added in the Linux header file:
this file has changed a bit since the last sync, now split in two files.
Only this new line is needed, so the minimum has been modified here.
Link: https://git.kernel.org/torvalds/c/539f6b9de39e [1]
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
It's possible that the first timeout gets delayed; therefore the
interval between the first and the second callback can be less than
one second, and the budget doesn't refill completely.
Schedule the second timeout from the first callback to guarantee that
at least one second passes between the callbacks.
Fixes: ff0c4346fc ('core: add rate-limiting helper')
Sending and receiving RA is repeated periodically. Don't spam logs
with the same message again and again. Rate limit the message to 6
every 12 hours per type and per ndisc instance.
Using nm_device_create_l3_config_data_from_connection in favor of
nm_l3_config_data_new_from_connection allows the connection
properties: connection.mdns, connection.llmnr,
connection.dns-over-tls, connection.dnssec, connection.mptcp-flags,
and ipv6.ip6-privacy to be read from the vpn's connection settings
allowing them to be applied to vpn connections.
Currently nm_device_create_l3_config_data_from_connection uses the
connection applied to the given device for some properties. Altough
this currently works since all users of
nm_device_create_l3_config_data_from_connection provide the applied
connection as parameter, it behaves unexpectedly when another
connection is given.
This is needed to ensure that the right CleanupType is chosen when
calling to nm_device_state_changed() a bit later. With this change
CLEANUP_TYPE_REMOVED will be used instead of CLEANUP_TYPE_DECONFIGURE,
which is wrong because the device has already disappeared.
As we introduced the ipv4.forwarding property in a8a2e6d727 ('ip-config:
Support configuring per-device IPv4 sysctl forwarding option'), we must
not enable or disable the global forwarding setting in the kernel, as it
affects to all the devices, maybe forcing them to behave in a way
different to what the user requested in ipv4.forwarding.
Instead, we need to selectively enable or disable the per-device forwarding
settings. Specifically, only devices activated with ipv4.forwarding=auto
must have their forwarding enabled or disabled depending on shared
connections. Devices with yes/no must not be affected by shared connections.
Also, devices with ipv4.forwarding=auto must get the proper forwarding value
on activation, but also change it when shared connections appear or
disappear dynamically. Use the new sharing-ipv4-change signal from
nm_manager to achieve it.
Fixes: a8a2e6d727 ('ip-config: Support configuring per-device IPv4 sysctl forwarding option')
This signal notifies about the "sharing state", that's it, when there
is at least one shared connection active or not. Each device informs
to nm_manager when a shared connection is activated or deactivated
and nm_manager emits this signal when the first shared connection is
activated or the last one is deactivated.
For now we're only interested in IPv4 forwarding as it's the only one
that we need to track from nm_device (in following commits).
Fixes: a8a2e6d727 ('ip-config: Support configuring per-device IPv4 sysctl forwarding option')
With the ipv4.forwarding property we may modify the forwarding sysctl of
the device on activation. In next commits, we will also modify it if the
connection is shared, instead of modifying the global forwarding.
Restore the forwarding value to the default one when the device is
deconfigured for any reason.
Fixes: a8a2e6d727 ('ip-config: Support configuring per-device IPv4 sysctl forwarding option')
This reverts commit 2ad5fbf025.
It is actually a partial revert. The changes to documentation don't need
to be reverted.
Fixes: 2ad5fbf025 ('policy: refresh IPv4 forwarding after connection activation and disconnection')
Trying to resolve hosts using localhost errors out for ipv6 attempts:
$ host www.seznam.cz localhost
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:
www.seznam.cz has address 77.75.77.222
www.seznam.cz has address 77.75.79.222
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
www.seznam.cz has IPv6 address 2a02:598:a::79:222
www.seznam.cz has IPv6 address 2a02:598:2::1222
;; communications error to ::1#53: connection refused
;; communications error to ::1#53: connection refused
It's because on some distros (like openSUSE), localhost is defined both
as 127.0.0.1 and ::1.
So listen on ::1 too. This makes ipv4-switchoff easier.
/etc/resolv.conf should likely be updated to contain ::1 eventually too
(see update_dns()).
Fixes https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1188
Using g_file_set_contents() makes it impossible to write a proper
SELinux policy because the function creates a file with a random
suffix, and SELinux file transitions can't match on wildcards.
Use a fixed temporary file name. In this case it's fine because
/run/NetworkManager is only writable by root and NetworkManager is the
only process writing into it.
These lines says things like "changed a bridge", what seems to mean that
NM is doing the change. Actually, these logs indicate changes that NM is
being notified of, and they may even be external changes.
- Add the "monitor:" prefix to show that it's something that NM is
monitoring, not doing.
- Say "bridge changed" instead of "changed a bridge", which sounds an
action that we're doing.
- Print the bridge/port/iface name first, instead of the uuid-like key which
is not useful for a quick look by a human.
- Print `connection=conn-uuid` instead of just `conn-uuid`, as it's not
obvious that the uuid refers to the connection.
Before:
ovsdb: obj[bridge:8c975244-cb0a-4add-8901-c398dcbc27d6]: changed a bridge: br-int, b1ef934d...
After:
ovsdb: monitor: br-int: bridge changed: obj[bridge:8c975244-cb0a-4add-8901-c398dcbc27d6], connection=b1ef934d...
If a feature like Wi-Fi, OVS, team, etc. is disabled or no longer
supported, it is better to report an error when the connection is
added via nmcli than accepting the connection and complaining later
about a "missing plugin"; there is no plugin and the connection will
never be able to activate.
Example errors now:
# nmcli connection add type team
Error: Failed to add 'team-nm-team' connection: team support is disabled in this build
# nmcli connection add type gsm
Error: Failed to add 'gsm' connection: WWAN support is disabled in this build
# nmcli connection add type wimax nsp 00:99:88:77:66:55
Error: Failed to add 'wimax' connection: WiMAX is no longer supported
Note that we don't touch libnm-core (the part defining the settings
and properties), as that defines the API of NetworkManager. The API
should not change according to compile flags.
When authenticating via 802.1X, the supplicant must be made aware of
the bridge the interface is attached to. This was already done for
wifi in commit ae31b4bf4e ('wifi: set the BridgeIfname supplicant
property when needed'). When setting the BridgeIfname property, the
supplicant opens an additional socket to listen on the bridge, to
ensure that all incoming EAPOL packets are received.
Without this patch, the initial authentication usually works because
it is started during stage2 (prepare), when the device is not yet
attached to the bridge, but then the re-authentication fails.
Note: I could reproduce the problem only when the bridge is configured
with bridge.group-forward-mask 8.
Resolves: https://issues.redhat.com/browse/RHEL-121153https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2301
