From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Daniel Mack <daniel@zonque.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: Issues with netdev egress hooks
Date: Thu, 7 Mar 2024 17:24:11 +0100 [thread overview]
Message-ID: <ZenqK_1HBMutR10u@calendula> (raw)
In-Reply-To: <07000633-1191-445d-b894-8a1d8b0c9044@zonque.org>
Hi Daniel,
On Thu, Mar 07, 2024 at 02:34:38PM +0100, Daniel Mack wrote:
> On 3/6/24 19:17, Pablo Neira Ayuso wrote:
[...]
> > I guess you are running a kernel with
> >
> > commit 0ae8e4cca78781401b17721bfb72718fdf7b4912
> > Author: Pablo Neira Ayuso <pablo@netfilter.org>
> > Date: Thu Dec 14 11:50:12 2023 +0100
> >
> > netfilter: nf_tables: set transport offset from mac header for netdev/egress
> >
> > so this is a different bug?
>
> Interesting, I did in fact run a 6.4 production kernel when I tried
> this, and that didn't have that patch applied. Sorry for that oversight.
>
> On 6.7, what I see is different but still broken:
I'm here with 6.8.0-rc6+:
> This rules does the right thing and patches the source MAC correctly:
>
> table netdev dummy {
> chain egress {
> type filter hook egress device dummy priority 0;
> ether saddr set 1:2:3:4:5:6 dup to eth0
> }
> }
>
> Whereas trying to patch the IP source addr leads to no packets being
> forwarded at all anymore:
My setup:
# ip link set up dev dummy
# ip a a 10.141.10.1/24 dev dummy
# ip ro del local 10.141.10.1 dev dummy table local proto kernel scope host src 10.141.10.1
testing with ping to 10.141.10.1
I need to remove the local route, otherwise packets go through
loopback interface.
> table netdev dummy {
> chain egress {
> type filter hook egress device dummy priority 0;
> ip saddr set 1.1.1.1 dup to eth0
> }
> }
1) tcpdump in dummy:
17:14:42.939483 f2:20:1a:4c:c4:a1 > f2:20:1a:4c:c4:a1, ethertype IPv4 (0x0800), length 98: 1.1.1.1 > 10.141.10.1: ICMP echo request, id 46403, seq 1, length 64
2) tcpdump in eth0:
17:15:21.006853 f2:20:1a:4c:c4:a1 > f2:20:1a:4c:c4:a1, ethertype IPv4 (0x0800), length 98: 1.1.1.1 > 10.141.10.1: ICMP echo request, id 1087, seq 1, length 64
> Interestingly, ether type filtering is also broken now, the following
> also doesn't match any packets:
>
> table netdev dummy {
> chain egress {
> type filter hook egress device dummy priority 0;
> ether type ip dup to eth0
> }
> }
1) tcpdump in dummy
17:18:13.921128 f2:20:1a:4c:c4:a1 > f2:20:1a:4c:c4:a1, ethertype IPv4 (0x0800), length 98: 10.141.10.1 > 10.141.10.1: ICMP echo request, id 137, seq 1, length 64
2) tcpdump in eth0:
17:19:00.398882 f2:20:1a:4c:c4:a1 > f2:20:1a:4c:c4:a1, ethertype IPv4 (0x0800), length 98: 10.141.10.1 > 10.141.10.1: ICMP echo request, id 21186, seq 1, length 64
> I browsed through the patches since 6.7 and couldn't find anything that
> is related. Did I miss anything?
I tried again this first example you posted:
table netdev dummy {
chain egress {
type filter hook egress device "dummy" priority 0;
ether type ip ether saddr set 01:02:03:04:05:06 ip saddr set 1.1.1.1 dup to "eth0"
}
}
tcpdump dummy:
17:22:08.390312 01:02:03:04:05:06 > f2:20:1a:4c:c4:a1, ethertype IPv4 (0x0800), length 98: 1.1.1.1 > 10.141.10.1: ICMP echo request, id 47168, seq 1, length 64
tcpdump enps25:
17:20:28.298524 01:02:03:04:05:06 > f2:20:1a:4c:c4:a1, ethertype IPv4 (0x0800), length 98: 1.1.1.1 > 10.141.10.1: ICMP echo request, id 15435, seq 1, length 64
Maybe my setup is different?
prev parent reply other threads:[~2024-03-07 16:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 15:43 Issues with netdev egress hooks Daniel Mack
2024-03-06 18:17 ` Pablo Neira Ayuso
2024-03-07 13:34 ` Daniel Mack
2024-03-07 16:24 ` Pablo Neira Ayuso [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZenqK_1HBMutR10u@calendula \
--to=pablo@netfilter.org \
--cc=daniel@zonque.org \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.