[nftables] frame rate limiting per day/minute not working (bug ?)

[ѽ҉ᶬḳ℠ <vtol@xxxxxxx>]

host: armv7l GNU/Linux
kernel: 5.10.0-rc3-next-20201113
nftables: v0.9.6
______

this rule in a > inet filter prerouting chain:

icmp type 8 add @b_sa4_lan_pinger { ip saddr limit rate over 2/day } log 
flags all prefix "ping_ip4 from LAN > rate_limit_d DROP: " drop;

Having tried different values, e.g.

limit rate over 2/day
limit rate over 44/day
limit rate over 300/day

frames # 1 -5 are always passing through but as of frame count # 6 the 
frames always being dropped, no matter the x/day value.


A somewhat inconsistent behaviour with x/minute value, e.g.

icmp type 8 add @b_sa4_lan_pinger { ip saddr limit rate over 13/minute } 
log flags all prefix "ping_ip4 from LAN > rate_limit_d DROP: " drop;

produces on the client side:

ping -4 -n 20 google.com

Pinging google.com [216.58.208.110] with 32 bytes of data:
Reply from 216.58.208.110: bytes=32 time=14ms TTL=114
Reply from 216.58.208.110: bytes=32 time=15ms TTL=114
Reply from 216.58.208.110: bytes=32 time=14ms TTL=114
Reply from 216.58.208.110: bytes=32 time=18ms TTL=114
Reply from 216.58.208.110: bytes=32 time=18ms TTL=114
Reply from 216.58.208.110: bytes=32 time=13ms TTL=114
Request timed out.
Reply from 216.58.208.110: bytes=32 time=14ms TTL=114
Request timed out.
Reply from 216.58.208.110: bytes=32 time=16ms TTL=114
Request timed out.
Reply from 216.58.208.110: bytes=32 time=16ms TTL=114
Reply from 216.58.208.110: bytes=32 time=13ms TTL=114
Request timed out.
Reply from 216.58.208.110: bytes=32 time=154ms TTL=114
Request timed out.
Reply from 216.58.208.110: bytes=32 time=32ms TTL=114
Reply from 216.58.208.110: bytes=32 time=13ms TTL=114
Request timed out.
Reply from 216.58.208.110: bytes=32 time=14ms TTL=114

Ping statistics for 216.58.208.110:
    Packets: Sent = 20, Received = 14, Lost = 6 (30% loss),
Approximate round trip times in milli-seconds:
    Minimum = 13ms, Maximum = 154ms, Average = 26ms


Whilst the count is matching the rule it is not clear why not all 13 
initial frames are passing through consistently and the excess being 
dropped consistently but instead the first being dropped is earlier?

Attachment: OpenPGP_signature
Description: OpenPGP digital signature