[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250814120753.1374735-1-gaoxingwang1@huawei.com>
Date: Thu, 14 Aug 2025 20:07:53 +0800
From: gaoxingwang <gaoxingwang1@...wei.com>
To: <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<davem@...emloft.net>, <bridge@...ts.linux.dev>,
<netfilter-devel@...r.kernel.org>, <idosch@...dia.com>,
<pablo@...filter.org>, <kadlec@...filter.org>
CC: <yanan@...wei.com>, <xuchunxiao3@...wei.com>, <huyizhen2@...wei.com>
Subject: netfilter: br_netfilter:NS packet was incorrectly matched by the nftables rule
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.
> 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?
Thanks if anyone can reply!
Powered by blists - more mailing lists