I have just tested it (again) by flushing the old ruleset and using the
following ruleset:
```
table ip filter {
counter test-icmp-output {
packets 3 bytes 252
}
counter test-icmp-input {
packets 0 bytes 0
}
chain INPUT {
type filter hook input priority filter; policy accept;
meta cgroup != 4096 ip saddr 8.8.8.8 ip protocol icmp counter name "test-icmp-input"
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
meta cgroup != 4096 ip daddr 8.8.8.8 ip protocol icmp counter name "test-icmp-output"
}
}
```
As previously, the cgroup 0x001000 does not exist. The three outbound
packets are the three ping packets, and they were successfully replied
to.
Martin Gignac <martin.gignac@xxxxxxxxx> writes:
> What is the complete output of 'nft list ruleset'?
>
> Is it possible you have an earlier INPUT rule that matches and allows
> packets that match connection-tracking "established" state, such as:
>
> chain INPUT {
> type filter hook input priority filter; policy drop;
> ct state established,related counter packets 391638047
> bytes 93651768866 accept
> ct state invalid drop
> [...]
>
> -Martin
>
>
> On Wed, Dec 8, 2021 at 4:39 AM Vladimir Nikishkin <lockywolf@xxxxxxxxx> wrote:
>>
>> Hello, everyone.
>>
>> I have a weird problem!
>>
>> This is my nft code:
>>
>> ```
>> nft add counter filter test-icmp-output
>> nft add counter filter test-icmp-input
>> nft add rule filter OUTPUT meta cgroup != 0x001000 ip daddr 8.8.8.8 ip protocol icmp counter name test-icmp-output
>> nft add rule filter INPUT meta cgroup != 0x001000 ip saddr 8.8.8.8 ip protocol icmp counter name test-icmp-input
>> ```
>>
>> Pinging 8.8.8.8 works. The packets are visible on tcpdump too.
>> The cgroup id 0x001000 does not exist, so every packet should match.
>>
>> Still, the output counter counts the expected number of packets, the
>> second stays 0.
>>
>> What am I doing wrong?
>>
>> --
>> Your sincerely,
>> Vladimir Nikishkin (MiEr, lockywolf)
>> (Laptop)
--
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)
