UDP checksum with nftables

using VLAN I had to modify UDP packets as the checksum is not calculated causing issues with dhcp process.
With iptables I used
iptables -A POSTROUTING -t mangle -p udp --dport 68 -j CHECKSUM --checksum-fill
THX to: https://forum.openwrt.org/t/solved-dhcp-on-vlan-interfaces/61115/6

How to do this using nftables as I didn't found the nft-checksum package?

Shall I stay using old iptables rules and use the fw4_compatible option?


I've read that setting the checksum to 0 will force its recalculation. As a stab in the dark, maybe try:
nft add rule inet fw4 mangle_postrouting ip protocol udp udp checksum set 0
EDIT - this may work a little more selectively:
nft add rule inet fw4 mangle_postrouting udp dport 68 udp checksum set 0

Look like instead of a "bad checksum" status it is a "no checksum" that is reported using tcpdump.
Moreover this prevents the DHCP process to complete
Doesn't work

That's disappointing, but not altogether unexpected. The --checksum-fill option of iptables is actually often used as an example of a type of iptables command that iptables-translate can't translate to nftables format. I had read that setting it to zero caused it to be recomputed, but that may be in more recent kernels as a solution to the above.

nftables is good for the middle of the bell-curve situations, but still seems to lack a lot of the flexibility in various fringe cases that iptables had. It's been around a long time, but I question it being ready for prime time.

This all smells like a bug, iptables or nftables shouldn't have to be involved.
What device is this?

To va1der:
Ok THX, I found the same on the internet while googleling. Will stay using iptables.

To znevna:
Using a RT3200 with VLAN. Don't think it's a device bug because previously I had the same behavior while using a WRT32X

Even so, messing with a firewall shouldn't be required to fix checksums.
Cosider filing a bug report.

1 Like

FYI - tcpdump cannot be used for accurately viewing an egressing packet's checksum.

Obviously the capture should be done on a client with checksum offload disabled, yes.

I'm not sure if you're replying to my post - but I wasnt referring to offloading.

I should add that running tcpdump on the client (instead of the OpenWrt) should work.

Yes, it was a reply to your post, and an addition, proper capture to find any bugs should be done on a client that has checksum offloading disabled on its interface, else the checksum reported will be bad anyway, if my previous reply wasn't clear enough, sorry.

1 Like

Sorry not an expert
what do you mean by checksum offload disabled on the interface?