On Tue, Apr 30, 2019 at 10:41:09PM +0200, Mikhail Morfikov wrote:
> On 07/04/2019 16:26, Mikhail Morfikov wrote:
> > Sets in nftables can have different sizes to prevent memory
> > exhaustion, and this can be set via the *size* option, for
> > instance:
> >
> > add set netdev traffic-control meter-icmp { type ipv4_addr; flags dynamic; timeout 60s; size 1; }
> >
> > I intentionally set the size=1 to see what happens when
> > I ping my machine from two different hosts.
> >
> > I also have the following rules:
> >
> > add rule netdev traffic-control INGRESS iif !="lo" ip protocol vmap { tcp:jump chain-tcp, icmp:jump chain-icmp }
> > add rule netdev traffic-control chain-icmp add @meter-icmp { ip saddr limit rate over 10/minute burst 1 packets } counter drop
> > add rule netdev traffic-control chain-icmp counter accept
> >
> > As I expected only the first IP goes to the set:
> >
> > set meter-icmp {
> > type ipv4_addr
> > size 1
> > flags dynamic,timeout
> > timeout 1m
> > elements = { 192.168.1.150 expires 27s64ms limit rate over 10/minute }
> > }
> >
> > And what surprised me was that only the listed host
> > got limited. The other one can ping my machine without
> > any issues. Should that happen?
> >
> > Basically I expected something like dropping packets
> > altogether from the other host that match the "drop"
> > rule above, since there's no room to add another entry
> > to the set. But it looks like, the rule is ignored and
> > packets hit the second rule.
> >
> > So if the size is reached, the packets can go through
> > the filter without any control?
> >
> *Bump*
Looks like a bug, the action "counter drop" seems to be ignore.
Does this counter bump once the set is full?
I'm refering to this rule:
add rule netdev traffic-control chain-icmp add @meter-icmp { ip saddr limit rate over 10/minute burst 1 packets } counter drop
