When CLAT is enabled, we want to also enable and honor by default DHCP
option 108 (IPv6-only preferred), so that the host can avoid
requesting an IPv4 address and go IPv6-only.
ICMPv6 error messages contain a copy of the original packet that
caused the error. In a 464XLAT deployment, this inner packet is an
IPv6 packet (as translated by the PLAT), while the local host expects
to see the original IPv4 packet it generated.
Without translation, the local host can't match the error to an active
socket. This breaks functionality like Path MTU Discovery (PMTUD),
traceroute, and error reporting for connected UDP sockets.
This commit implements the translation of the inner headers from IPv6
to IPv4 for incoming ICMPv6 errors.
Some implementation notes:
- this only handles incoming ICMPv6; outgoing ICMPv4 is not yet
implemented, but it seems less important.
- the program uses different functions for rewriting the outer and
inner header. I tried using recursion but the verifier didn't seem
to like it.
- after rewriting the inner headers, the ICMP checksum is
incrementally updated based on difference of all the individual
modifications done to the inner headers. This has the advantage
that all the operations are fixed-size. But probably it would be
easier and faster to just calculate the checksum from scratch.
The program only needs to know the local IPv4 address, the local IPv6
address and the PREF64. There is no need to create multiple maps for
that, just pass a global configuration struct containing those 3
fields.
Improve the code style and consistency of some functions:
- declare only one variable per line
- add "const" keyword to read-only function arguments
- remove unneeded function arguments
- rename variables holding headers on the stack with the "_buf"
suffix
Avoid using pointer arithmetic in the BPF program, so that it requires
only CAP_BPF and not CAP_PERFMON. In this context "pointer arithmetic"
means adding a variable value to a packet pointer. This means that the
program no longer tries to parse variable-size headers (IPv4 options,
IPv6 extension headers). Those were already not supported before. It
also doesn't parse VLAN tags, but there should be no need for that. If
we use fixed offset, we can avoid using the parsing helpers from
libxdp.
There are 3 possible results from clat_translate_v6():
1. the packet didn't match the CLAT IPv6 address and must be
accepted;
2. the packet matches but it is invalid and so it must be dropped;
3. the packet matches and it is valid; clat_handle_v6() should
translate the packet to IPv4;
Before, the function returned TC_ACT_SHOT for both 2 and 3. Therefore,
clat_handle_v6() tried to rewrite also invalid packets.
Fix that by returning TC_ACT_UNSPEC for valid packets, meaning that
there isn't a final verdict yet.
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
