nftables dynamic blacklisting both IPv4 and IPv6

Question

In setting up dynamic blacklists for nftables, per A.B.'s excellent answer, I'm encountering an error when duplicating the blacklist for both ipv4 and ipv6. I perform the following command-line operation (debian nftables) (EDIT: The original question was for a prior version, 0.9.0; during the back-and-forth comment process, it was upgraded to the more current version 0.9.3, so the accepted answer below is valid for the version 0.9.3 API):

nft flush ruleset && nft -f /etc/nftables.conf

for a config file including:

tcp flags syn tcp dport 8000 meter flood size 128000 { ip  saddr timeout 20s limit rate over 1/second } add @blackhole_4 { ip  saddr timeout 1m } drop
tcp flags syn tcp dport 8000 meter flood size 128000 { ip6 saddr timeout 20s limit rate over 1/second } add @blackhole_6 { ip6 saddr timeout 1m } drop
tcp flags syn tcp dport 8000 meter greed size 128000 { ip  saddr ct count over 3 } add @blackhole_4 { ip  saddr timeout 1m } drop                                                         
tcp flags syn tcp dport 8000 meter greed size 128000 { ip6 saddr ct count over 3 } add @blackhole_6 { ip6 saddr timeout 1m } drop

and get the following error response:

/etc/nftables.conf:130:17-166: Error: Could not process rule: Device or resource busy
                tcp flags syn tcp dport 8000 meter flood size 128000 { ip6 saddr timeout 20s limit rate over 1/second } add @blackhole_6 { ip6 saddr timeout 1m } drop
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/etc/nftables.conf:132:17-145: Error: Could not process rule: Device or resource busy
                tcp flags syn tcp dport 8000 meter greed size 128000 { ip6 saddr ct count over 3 } add @blackhole_6 { ip6 saddr timeout 1m } drop
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Also, I'm not sure what the size is a measure of; it's set to 128000 because that's what I saw somewhere authoritative.

EDIT: Okay. I decided to continue playing, and see that creating separate meters for each ipv6 rule causes the error message to go away, but I don't understand why, so instead of answering my own question, I'll leave it open for someone who has a knowledgeable explanation why the meters can't be shared. The following produces no errors:

tcp flags syn tcp dport 8000 meter flood_4 size 128000 { ip  saddr timeout 20s limit rate over 1/second } add @blackhole_4 { ip  saddr timeout 1m } drop
tcp flags syn tcp dport 8000 meter flood_6 size 128000 { ip6 saddr timeout 20s limit rate over 1/second } add @blackhole_6 { ip6 saddr timeout 1m } drop
tcp flags syn tcp dport 8000 meter greed_4 size 128000 { ip  saddr ct count over 3 } add @blackhole_4 { ip  saddr timeout 1m } drop                                                         
tcp flags syn tcp dport 8000 meter greed_6 size 128000 { ip6 saddr ct count over 3 } add @blackhole_6 { ip6 saddr timeout 1m } drop

EDIT: At the time of this writing, the man pages for nftables use the term meter, but according to the nftables wiki, the term has been deprecated in favor of set, which requires a definition including a specific protocol type (eg. ipv4_addr), so if nftables is currently mapping the term meter to the newer set, that would explain why a single meter can't currently be shared between ipv4_addr and ipv6_addr. However, the example given in the nftables wiki itself is also not up-to-date: it generates an error because dynamic is not currently (nftables v0.9.0) a valid flag type. Back to the man pages, and we can see that set has flags of either type constant, interval, or timeout, and I'm uncertain which would be appropriate for this purpose.

EDIT: The "count" form of metering seems to have moved to a separate part of nftables: ct (connection tracking). It seems that one should now create defintions such as:

    set greed_4 {                                                                                                                                                                                 
        type ipv4_addr                                                                                                                                                                            
        flags constant                                                                                                                                                                            
        size 128000                                                                                                                                                                               
        }                                                                                                                                                                                         

    set greed_6 {                                                                                                                                                                                 
        type ipv6_addr                                                                                                                                                                            
        flags constant                                                                                                                                                                            
        size 128000                                                                                                                                                                               
        }                                                                                                                                                                                         

and then the following rules may be close, but still generate errors:

ct state new add @greed_4 { tcp flags syn tcp dport 8000 ip saddr ct count over 3 } add @blackhole_4 { ip saddr timeout 1m } drop
ct state new add @greed_6 { tcp flags syn tcp dport 8000 ip6 saddr ct count over 3 } add @blackhole_6 { ip6 saddr timeout 1m } drop

Answer 1

try this one

table inet filter {
  set blackhole_4 {
    type ipv4_addr
    flags timeout
  }
  set blackhole_6 {
    type ipv6_addr
    flags timeout
  }
  set greed_4 {
    type ipv4_addr
    flags dynamic
    size 128000
  }
  set greed_6 {
    type ipv6_addr
    flags dynamic
    size 128000
  }
  chain input {
    type filter hook input priority 0;
    ct state new tcp flags syn tcp dport 8000 add @greed_4 { ip saddr ct count over 3 } add @blackhole_4 { ip  saddr timeout 1m } drop
    ct state new tcp flags syn tcp dport 8000 add @greed_6 { ip6 saddr ct count over 3 } add @blackhole_6 { ip6  saddr timeout 1m } drop
  }
}

EDIT: Explanation from @User1404316: Since @Zip May (correctly) asked for some explanation. As I understand it: ct introduces a connection tracking rule, in this case for new tcp connections, that if they are heading for port 8000 (dport is destination port), add the source IPv4 to the pre-defined collection set greed_4. If that happens, the rule continues with the first bracket condition, that if the source address has more than three active connections, add the source IPv4 to the second predefined set blackhole_4, but only keep it there for one minute, and if we have gotten this far along in the rule, then drop the connection.

The original posted answer had two of its long lines truncated, but I figured out what I think they should be and inserted them above. The good news is that my testing indicates that this answer works!

A remaining curiousity for me is how to decide when to set sizes for the collection sets, and how large to make them, so I just left things the way they are for now.