I'm trying to hashlimit/recent in nftables. My old example rulesets are: http://cyber.com.au/~twb/doc/iptab http://cyber.com.au/~twb/doc/iptab.ips (adds hashlimit/recent/CHAOS). My test nftables ruleset seems to be working: http://cyber.com.au/~twb/tmp/nftables-just-ips.nft These things confused me: * The wiki[1] says "the meter keyword is obsolete", but "man nft" (v0.9.1) and "iptables-translate" (v1.8.3) both still use it. Is there a way to change a meter rule into a map rule? I can't work it out. I tried variations on the examples at [1], but I got generic parse errors with nft v0.9.1 and linux 4.19 or 5.0. [1] https://wiki.nftables.org/wiki-nftables/index.php/Meters * nft(8) gives a working "meter" example, but it's part of a SET example -- there is no seperate METER section with a detailed explanation of how meters work. * Named sets/maps have to be declared and used separately, e.g. add set inet my_filter my_set { type ipv4_addr; timeout 1m; }; add rule inet my_filter my_input update @my_set {ip saddr} Meters apparently get created and used in one go, e.g.: add rule inet my_filter my_input meter my_filter {ip saddr timeout 1m limit rate 10/second} * Elements of sets/maps are listed in "nft list ruleset". Elements of a meter aren't. You can still see them with "nft list set/map/meter", though. * In the examples, it's not clear (to me) what's a keyword, and what's a user-supplied name. For example, I interpreted this rule as editing a meter named @blackhole, with a constraint that the "flood size" was above(?) 128000 (packets?). Then I went looking all over for documentation for the "flood size" keyword. PS: Can we please change the examples so user-supplied names have an obvious prefix like "my_" -- visibly distinct from keywords? The textbook example of this confusion is here: table filter chain input { type filter hook input priority filter; policy accept } } To an nftables novice, it's not clear that "filter" and "filter" (or "input" and "input") are different things (a name and a keyword). It's not obvious that you can change the former, but not the latter. I think this makes it a more obvious, even though you wouldn't actually use "my_" in a real ruleset: table my_filter chain my_input { type filter hook input priority filter; policy accept } } PPS: I also think double-spacing between clauses helps readability, e.g. iifname dmz ip daddr ldap.example.com tcp dport ldaps accept comment "Centralized authentication" becomes iifname dmz ip daddr ldap.example.com tcp dport ldaps accept comment "Centralized authentication" An alternative is to quote the "argument" at the end of each clause, but a) space bar is easier to type; and b) I'm not sure quotes are always allowed there.