Bug 2321716

Summary: Podman cannot start container ip ipv6 network, ip6table has no --set-xmark option
Product: [Fedora] Fedora Reporter: Patrice FERLET <metal3d>
Component: podmanAssignee: Lokesh Mandvekar <lsm5>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 40CC: bbaude, debarshir, dwalsh, go-sig, jnovy, lsm5, mboddu, mheon, patrick, santiago, suraj.ghimire7
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-10-25 09:11:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Patrice FERLET 2024-10-25 09:03:07 UTC
Description of problem:

Creating a podman network with IPV6 and starting a Pod / Container inside fails. The problem is that the `--set-xmark` option for ip6table is not known. Whatever if I manually insert the kernel module `xt_mark`.

It seems that this option is related to `xt_CONNMARK` which is not present. See: https://www.netfilter.org/pub/iptables/iptables-1.4.1-rc2/extensions/libxt_CONNMARK.c

Version-Release number of selected component (if applicable):

5.2.3

How reproducible:


Steps to Reproduce:
1. `podman network create --ipv6 foo`
2. `podman run --rm -it --network foo docker.io/nginx`


Actual results:

```
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?
ip6tables v1.8.10 (nf_tables): unknown option "--set-xmark"
Try `ip6tables -h' or 'ip6tables --help' for more information.
```

Expected results:

A working container running inside the corresponding network.

Additional info:

It make impossible to start a local kubernetes instance using `kind`. The workaround is to create a network named `kind` without ipv6, and start `kind create cluster` afterward.

See https://github.com/kubernetes-sigs/kind/issues/3765

Comment 1 Patrice FERLET 2024-10-25 09:09:45 UTC
It seems to be linked to 2321325 bug actually

Comment 2 Patrice FERLET 2024-10-25 09:11:59 UTC

*** This bug has been marked as a duplicate of bug 2321325 ***