When copying the IPv6 addresses via a direct assignement, the compiler
generates 32-bit operations that the verifier doesn't like:
> 237: (61) r3 = *(u32 *)(r8 +76) ; frame1: R3_w=pkt(r=0) R8=ctx()
> ; .saddr = ip6h->saddr, @ clat.bpf.c:124
> 238: (63) *(u32 *)(r10 -64) = r3
> invalid size of register spill
Use explicit memcpy() for those.
Also, check the packet length before accessing the ICMPv6 header.
The current implementation returns IP addresses obtained by adding a
counter to a base address. For CLAT we want to return all the 8
addresses in the 192.0.0.0/29 range, but not starting from 192.0.0.0
because that looks more like a network address. Slightly tweak the
algorithm so that addresses can wrap around.
Update the lists of ignored phrases and words which are to be stripped
from product names, to remove product capabilities, the bus the product
attached on and similar nonsense.
Add tests for the product names which these additions are intended for.
Since it is error prone to manually type in interface names to match existing
ones, we introduce a select button that allows a user to chose from a list of devices.
- Show "Select..." button for physical devices to choose from available
devices in a popup dialog.
- devices are sorted in alphabetical order.
- Only for physical devices (ethernet, infiniband, wifi, etc)
Resolves: https://issues.redhat.com/browse/RHEL-129186
Fix the following error:
In function ‘_nm_auto_unref_ptrarray’,
inlined from ‘nmt_connect_connection_list’ at ../src/nmtui/nmtui-connect.c:593:34,
inlined from ‘nmtui_connect’ at ../src/nmtui/nmtui-connect.c:673:16:
../src/libnm-std-aux/nm-std-aux.h:1106:12: error: ‘all_active_wifi_devices’ may be used uninitialized [-Werror=maybe-uninitialized]
1106 | if (*v) \
| ^
../src/nmtui/nmtui-connect.c: In function ‘nmtui_connect’:
../src/nmtui/nmtui-connect.c:593:34: note: ‘all_active_wifi_devices’ was declared here
593 | gs_unref_ptrarray GPtrArray *all_active_wifi_devices;
Fixes: 221da3f8c0 ('nmtui: feature: wifi-rescan feature for the nmtui.')
On a i686 machine the build fails with:
../src/nm-cloud-setup/main.c: In function ‘_oci_new_vlan_dev’:
../src/nm-cloud-setup/main.c:800:47: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘gssize’ {aka ‘int’} [-Werror=format=]
800 | macvlan_name = g_strdup_printf("macvlan%ld", config_data->iface_idx);
| ~~^ ~~~~~~~~~~~~~~~~~~~~~~
| | |
| long int gssize {aka int}
| %d
../src/nm-cloud-setup/main.c:801:42: error: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘gssize’ {aka ‘int’} [-Werror=format=]
801 | connection_id = g_strdup_printf("%s%ld", connection_type, config_data->iface_idx);
| ~~^ ~~~~~~~~~~~~~~~~~~~~~~
| | |
| long int gssize {aka int}
| %d
Fixes: 68d7e17737 ('Reapply "cloud-setup: create VLANs for multiple VNICs on OCI"')
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.
It's a valuable information for users, especially because the channel
number can be ambiguous.
Before:
$ nmcli device wifi
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
42:00:00:AA:DD:CC test Infra 44 1170 Mbit/s 85 ▂▄▆█ WPA2
92:00:00:AB:DD:CC guest Infra 44 1170 Mbit/s 85 ▂▄▆█ WPA2
After:
$ nmcli device wifi
IN-USE BSSID SSID MODE BAND CHAN RATE SIGNAL BARS SECURITY
42:00:00:AA:DD:CC test Infra 5 GHz 44 1170 Mbit/s 85 ▂▄▆█ WPA2
42:00:00:AB:DD:CC guest Infra 5 GHz 44 1170 Mbit/s 85 ▂▄▆█ WPA2
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
It's clearer this way, and it will allow to modify directly the
"Version:" and "Release:" fields to bump the version. It is more aligned
with the layout of other projects' spec files too.
Snapshot is only used from nm-copr-build.sh script, so not very useful.
Git_sha is used from build.sh. Other than that, downstream is always
nil.
Remove them and modify build.sh to use --define "dist xxx" instead of
them. This change is motivated by Packit not being able to modify the
release number if it has the %{snap} suffix.
When dist_version is defined in meson, NM installs plugins to a
directory called `NetworkManager-${dist_version}`. If the dist version
contains a `~`, like `1.56~rc1`, defining nmplugindir with
`%{version_no_tilde}` makes it `NetworkManager-1.56-rc1`, causing
rpmbuild errors due to the mismatch.
Fix it by defining nmplugindir with `%{version}` instead.
Fixes: d975389bcd ('spec: use versioning scheme with ~dev and ~rc suffixes')
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')
