With OpenWrt 25.12.2, there is weirdness with nft reset when done on a set with counters. Counters seem to reset to something like maxint(u32)+1, instead of zero.
This works fine on Ubuntu 26.04 which has the same version of nft
M
root@wg4300:/tmp# nft list table ip p4
table ip p4 {
set BADLAN4 {
typeof ip daddr
flags interval
counter
elements = { 100.64.0.0/10 counter packets 1 bytes 84 }
}
chain out {
type filter hook output priority filter; policy accept;
ct state established counter packets 36 bytes 8144 accept
ip daddr @BADLAN4 counter packets 1 bytes 84 reject
}
}
root@wg4300:/tmp# nft reset set p4 BADLAN4
table ip p4 {
set BADLAN4 {
typeof ip daddr
flags interval
counter
elements = { 100.64.0.0/10 counter packets 1 bytes 84 }
}
}
root@wg4300:/tmp# nft reset set p4 BADLAN4
table ip p4 {
set BADLAN4 {
typeof ip daddr
flags interval
counter
elements = { 100.64.0.0/10 counter packets 4294967296 bytes 4294967296 }
}
}
root@wg4300:~# nft -V
nftables v1.1.6 (Commodore Bullmoose #7)
I have discovered this problem as well and have been tying to track down whether it is an OpenWrt problem or nftables.
So far it only fails on 32bit devices (TpLink Archer C7 & ZTE MF286D only tested) but works fine on the 64bit RaspberryPi 3B+
I have recently tested on a 32bit Raspberry Pi v1.2 using Trixie based RaspiOs and that works correctly which seems to point to a problem in OpenWrt.
As a workaround, you can do a list and flush, but that comes with the caveat that there may be packets missed between the two commands.
Advice on where to report the problem would be appreciated, if here is not appropriate.
Nice that somebody else also noticed it.
Is your pi3 running OpenWrt or more mainstream Linux?
I just tested it on a 64bit OpenWrt Cudy travel router (very sweet device). Seems to work correctly.
So you maybe it is a 32 bit cpu issue.
root@cudyA:~# nft reset set p4 BADLAN4
table ip p4 {
set BADLAN4 {
typeof ip daddr
flags interval
counter
elements = { 100.64.0.0/10 counter packets 1 bytes 84 }
}
}
root@cudyA:~# nft reset set p4 BADLAN4
table ip p4 {
set BADLAN4 {
typeof ip daddr
flags interval
counter
elements = { 100.64.0.0/10 counter packets 0 bytes 0 }
}
}
root@cudyA:~# uname -a
Linux cudyA 6.12.74 #0 SMP Wed Mar 25 20:09:53 2026 aarch64 GNU/Linux
It's running Openwrt 25.12.2. Linux OpenWrt-Pi 6.12.74 #0 SMP Wed Mar 25 20:09:53 2026 aarch64 GNU/Linux.
I have not found the problem on mainstream Linux at all, but was only able to recently test a 32bit raspberry pi. Testing anything else is a problem as older Debian versions use nftables prior to the implementation of 'nft reset'
I just tried 32 bit alpine linux on a pi 3. No issue seen.
The nftables version is one previous to what is in OpenWrt 25.12.2
alps:~# uname -a
Linux alps 6.12.85-0-rpi #1-Alpine SMP Mon May 4 13:52:56 UTC 2026 armv7l Linux
alps:~# nft -V
nftables v1.1.5 (Commodore Bullmoose #6)
cli: readline
json: yes
minigmp: no
libxtables: no
Upgraded my 32bit router to OpenWrt 25.12.4 last week and all seems to work as expected now. Same version of nftables as before so something has happened in the meantime!
root@owrt-386:~# uname -a
Linux owrt-386 6.12.87 #0 SMP Wed May 13 22:42:09 2026 armv7l GNU/Linux
root@owrt-386:~# nft -V
nftables v1.1.6 (Commodore Bullmoose #7)
cli: no
json: yes
minigmp: yes
libxtables: no
root@owrt-386:~# nft list set inet test ip4_rx
table inet test {
set ip4_rx {
type ipv4_addr
size 65535
flags dynamic
counter
elements = { 192.168.8.52 counter packets 3 bytes 197 }
}
}
root@owrt-386:~# nft reset set inet test ip4_rx
table inet test {
set ip4_rx {
type ipv4_addr
size 65535
flags dynamic
counter
elements = { 192.168.8.52 counter packets 4 bytes 266 }
}
}
root@owrt-386:~# nft list set inet test ip4_rx
table inet test {
set ip4_rx {
type ipv4_addr
size 65535
flags dynamic
counter
elements = { 192.168.8.52 counter packets 0 bytes 0 }
}
}