gaoxingwang [off-list ref] wrote:
Hello,everyone:
In my test case, the container (with net.bridge.bridge-nf-call-ip6tables=1 set) attempts
to ping the host's IPv6 address through a bridged network. Simultaneously, tcpdump is used to monitor
the bridge, and it is observed that the ping fails.
The direct cause of the ping failure is that the NS packet matches the "ct state invalid drop"
rule in nftables and is therefore discarded.
The commit 751de2012eafa4d46d80 introduced a modification to bridge traffic handling. When the bridge
is in promiscuous mode, it resets the conntrack state of the packets.
quoted
if (promisc) {
nf_reset_ct(skb);
return NF_ACCEPT;
}
IPv6 NS packets are untracked by default.When an IPv6 NS packet passes through the bridge and the bridge
is in promiscuous mode, the conntrack state of the packet is reset. If there is a firewall rule
such as "ct state invalid drop," the IPv6 NS packet will be deemed invalid and dropped, leading to
a ping failure issue.
Is this a bug, or is there an issue with my analysis?
net.bridge.bridge-nf-call-ip6tables and bridge conntrack are
incompatible.
Either use ipv6 conntrack with net.bridge.bridge-nf-call-ip6tables or
disable net.bridge.bridge-nf-call-ip6tables.