Hi Daniel,
On Wed, Mar 06, 2024 at 04:43:02PM +0100, Daniel Mack wrote:
> Hi,
>
> I am using the NFT egress hook in a netdev table with 'set' statements
> to adjust the source MAC and IP addresses before duplicating packets to
> another interface:
>
> 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"
> }
> }
Is this a dummy device created via: ip link add dummy type dummy or
just a coincidence?
> Does this rule look okay or am I holding it wrong?
Rule looks correct.
> The modification of the sender's MAC address works fine. However, the
> adjustment of the source IP is applied at the wrong offset. The octets
> in the raw packet that are being modified are 13 and 14, which would be
> the correct offset within an IP header, but it seems that the prefixed
> Ethernet header is not taken into account.
>
> For the same reason, attempting to filter based on any details beyond
> the Ethernet header also fails. The following rule does not match any
> packets, even though there is a significant amount of UDP traffic:
>
> table netdev dummy {
> chain egress {
> type filter hook egress device "dummy" priority 0;
> ether type ip ip protocol udp dup to "eth0"
> }
> }
>
> At this point, I'm not sure where to start digging to be honest and
> would appreciate any guidance on how to resolve this issue.
I guess you are running a kernel with
commit 0ae8e4cca78781401b17721bfb72718fdf7b4912
Author: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
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?
