Description of problem: Start podman container with IPv6 enabled: Oct 23 19:41:43 pi container[7777]: Error: netavark: unable to append rule '-j MARK --set-xmark 0x2000/0x2000' to table 'nat': code: 2, msg: Warning: Extension MARK revision 0 not supported, missing kernel module? Version-Release number of selected component (if applicable): $ uname -a Linux pi 6.11.4-201.fc40.aarch64 #1 SMP PREEMPT_DYNAMIC Sun Oct 20 15:16:03 UTC 2024 aarch64 GNU/Linux $ rpm-ostree status State: idle Deployments: ● fedora-iot:fedora/stable/aarch64/iot Version: 40.20241023.0 (2024-10-23T13:02:45Z) BaseCommit: 845fdcced41e473bf1571172d981afca0feefacd114cf9687bd118b3ff230a34 GPGSignature: Valid signature by 115DF9AEF857853EE8445D0A0727707EA15B79CC LayeredPackages: fish htop nano rsync samba How reproducible: Start container with Podman Quadlet + IPv6 enabled in network settings. Actual results: Start container Expected results: Container dies Additional info: https://www.fedoraproject.org/iot/download - Hopefully I've selected the correct component.
I am impacted by this also, as are all tailscale VPN users at https://github.com/tailscale/tailscale/issues/13863. I am running Fedora 40, kernel version 6.11.4 The root cause is believed to be a typo in netfilter, which is fixed at https://patchwork.ozlabs.org/project/netfilter-devel/patch/20241020124951.180350-1-pablo@netfilter.org/ I've reverted my kernel versions until the above patch lands. Current kernel versions of 6.11 and 6.6 (LTS) are both impacted. 6.11.3 is not impacted, nor is 6.1 (LTS). `tailscale status` .. cut .. # Health check: # - adding [-i tailscale0 -j MARK --set-mark 0x40000/0xff0000] in v6/filter/ts-forward: running [/usr/sbin/ip6tables -t filter -A ts-forward -i tailscale0 -j MARK --set-mark 0x40000/0xff0000 --wait]: exit status 2: Warning: Extension MARK revision 0 not supported, missing kernel module? ip6tables v1.8.10 (nf_tables): MARK: bad value for option "--set-mark", or out of range (0-4294967295). Try `ip6tables -h' or 'ip6tables --help' for more information. `uname -a` Linux fedora36-usb 6.11.4-201.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Oct 20 15:04:22 UTC 2024 x86_64 GNU/Linux `cat /etc/fedora-release` Fedora release 40 (Forty) (As always, I'd like to thank everyone in the Fedora community, I rely on your hard work every day. Thank y for all my computersou!)
Some additional information is at https://lore.kernel.org/all/efbf5943-f136-4330-b896-d6b7a2d02796@kernel.org/ which indicates that the fix is still being worked on.
Thanks for linking to the PR. :) Hopefully it will be solved soon, seems other distros are including this patch already, but it may be better to wait.
It then linked to my BR : https://bugzilla.redhat.com/show_bug.cgi?id=2321716
*** Bug 2321716 has been marked as a duplicate of this bug. ***
Actually, the problem is that xt_CONNMARK module is not present in Fedora. The option is here https://www.netfilter.org/pub/iptables/iptables-1.4.1-rc2/extensions/libxt_CONNMARK.c But modprobe refuse to load it, as it is not present.
OK, seems to be renamed to lowercase: https://git.netfilter.org/iptables/tree/extensions/libxt_connmark.c Weird, I loaded the xt_connmark module and the bug is still present.
And, last check... I cloned the iptables repo, then: git checkout v1.8.10 rep -nr "set-xmark" . ./extensions/libxt_CONNMARK.txlate:7:iptables-translate -t mangle -A PREROUTING -j CONNMARK --set-xmark 0x16/0x12 ./extensions/libxt_MARK.t:2:-j MARK --set-xmark 0xfeedcafe/0xfeedcafe;=;OK ./extensions/libxt_MARK.t:3:-j MARK --set-xmark 0x0;-j MARK --set-xmark 0x0/0xffffffff;OK ./extensions/libxt_MARK.t:4:-j MARK --set-xmark 4294967295;-j MARK --set-xmark 0xffffffff/0xffffffff;OK ./extensions/libxt_MARK.t:5:-j MARK --set-xmark 4294967296;;FAIL ./extensions/libxt_MARK.t:6:-j MARK --set-xmark -1;;FAIL ./extensions/libxt_CONNMARK.c:97: {.name = "set-xmark", .id = O_SET_XMARK, .type = XTTYPE_MARKMASK32, ./extensions/libxt_CONNMARK.c:123: {.name = "set-xmark", .id = O_SET_XMARK, .type = XTTYPE_MARKMASK32, ./extensions/libxt_CONNMARK.c:155:" --set-xmark value[/ctmask] Zero mask bits and XOR ctmark with value\n" ./extensions/libxt_CONNMARK.c:506: printf(" --set-xmark 0x%x/0x%x", info->ctmark, info->ctmask); ./extensions/libxt_CONNMARK.c:530: printf(" --set-xmark 0x%x/0x%x", info->ctmark, info->ctmask); ./extensions/libxt_MARK.c:59: {.name = "set-xmark", .id = O_SET_XMARK, .type = XTTYPE_MARKMASK32, ./extensions/libxt_MARK.c:76:" --set-xmark value[/mask] Clear bits in mask and XOR value into nfmark\n" ./extensions/libxt_MARK.c:157: xtables_error(PARAMETER_PROBLEM, "MARK: One of the --set-xmark, " ./extensions/libxt_MARK.c:245: printf(" --set-xmark 0x%x/0x%x", info->mark, info->mask); ./extensions/libxt_MARK.txlate:7:iptables-translate -t mangle -A OUTPUT -j MARK --set-xmark 0x40/0x32 I tried to load them lsmod | grep "xt_.*mark" xt_connmark 16384 0 xt_mark 12288 1 nf_conntrack 192512 11 xt_conntrack,xt_CONNSECMARK,nf_nat,nft_ct,nft_nat,nf_conntrack_netbios_ns,xt_nat,nf_conntrack_broadcast,xt_connmark,xt_MASQUERADE,ip_vs So, xt_connmark and xt_mark are well loaded. And the "--set-xmark" option is not present. Is there anything that was done on RPM build? Patches?
*** Bug 2321943 has been marked as a duplicate of this bug. ***
This bug has broken all my containers. As it looks it's an issue with a kernel module, I'm reassigning it. The bug was reported for aarch64 but I've also reproduced it in x86_64.
Any update on this? I cannot update to F41 at the moment. I don't follow upstream, what I understood the new kernel should fix this, but it hasn't released yet. I'm on Silverblue, so it's difficult to downgrade only the kernel.
(In reply to francois from comment #11) > Any update on this? > I cannot update to F41 at the moment. You can workaround the issue by configuring netavark to use the nftables backend and rebooting the host (this is the new default in F41): /etc/containers/containers.conf.d/50-netavark-nftables.conf: ~~~ [network] firewall_driver="nftables" ~~~ However note that when using nftables there's another nasty bug in netavark that will break the container network if they are restarted and they use the same port in TCP and UDP: https://bugzilla.redhat.com/show_bug.cgi?id=2322021
I was sent here from the tailscale bug https://github.com/tailscale/tailscale/issues/13863 Where tailscale status is returning: # Health check: # - adding [-i tailscale0 -j MARK --set-mark 0x40000/0xff0000] in v6/filter/ts-forward: running [/usr/sbin/ip6tables -t filter -A ts-forward -i tailscale0 -j MARK --set-mark 0x40000/0xff0000 --wait]: exit status 2: Warning: Extension MARK revision 0 not supported, missing kernel module? ip6tables v1.8.10 (nf_tables): MARK: bad value for option "--set-mark", or out of range (0-4294967295). this makes tailscale not work for any of my ipv6 connections on F41 Silverblue. If I'm placing this in the wrong place, please let me know.
(In reply to maxfridbe from comment #13) > I was sent here from the tailscale bug > https://github.com/tailscale/tailscale/issues/13863 > Where tailscale status is returning: > # Health check: > # - adding [-i tailscale0 -j MARK --set-mark 0x40000/0xff0000] in > v6/filter/ts-forward: running [/usr/sbin/ip6tables -t filter -A ts-forward > -i tailscale0 -j MARK --set-mark 0x40000/0xff0000 --wait]: exit status 2: > Warning: Extension MARK revision 0 not supported, missing kernel module? > ip6tables v1.8.10 (nf_tables): MARK: bad value for option "--set-mark", or > out of range (0-4294967295). > > this makes tailscale not work for any of my ipv6 connections on F41 > Silverblue. > > If I'm placing this in the wrong place, please let me know. also rebased to f40 and same issue with ip v6 so it does seem to be issue with Linux 6.11.5-200.fc40.x86_64
When is 6.11.6 going to be pushed on Silverblue and IoT?
I have received the kernel update on Silverblue 40/41 and IoT, seems more are reporting this. :) Thanks for looking into this.
(In reply to Juan Orti from comment #12) > (In reply to francois from comment #11) > > Any update on this? > > I cannot update to F41 at the moment. > > You can workaround the issue by configuring netavark to use the nftables > backend and rebooting the host (this is the new default in F41): > > /etc/containers/containers.conf.d/50-netavark-nftables.conf: > > ~~~ > [network] > firewall_driver="nftables" > ~~~ > > However note that when using nftables there's another nasty bug in netavark > that will break the container network if they are restarted and they use the > same port in TCP and UDP: > > https://bugzilla.redhat.com/show_bug.cgi?id=2322021 Thanks! I couldn't test this, but to be sure I have run the following commands after the latest kernel update: $ podman system migrate $ podman network update podman It seems to be working again.