On 9.4.2022 12.51, Florian Westphal wrote:
Topi Miettinen <toiwoton@xxxxxxxxx> wrote:
Kernel silently accepts input chain filters using meta skuid, meta
skgid, meta cgroup or socket cgroupv2 expressions but they don't work
yet. Warn the users of this possibility.
Signed-off-by: Topi Miettinen <toiwoton@xxxxxxxxx>
---
doc/nft.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/doc/nft.txt b/doc/nft.txt
index f7a53ac9..4820b4ae 100644
--- a/doc/nft.txt
+++ b/doc/nft.txt
@@ -932,6 +932,11 @@ filter output oif wlan0
^^^^^^^^^^^^^^^^^^^^^^^
---------------------------------
+Note that the kernel may accept expressions without errors even if it
+doesn't implement the feature. For example, input chain filters using
+*meta skuid*, *meta skgid*, *meta cgroup* or *socket cgroupv2*
+expressions are silently accepted but they don't work yet.
Thats not correct.
Those expressions load values from skb->sk, i.e. the socket associated
with the packet.
In input, such socket may exist, either because of tproxy rules, early
demux, or bpf programs.
Thanks. How about:
Note that the kernel may accept expressions without errors even if it
doesn't implement the feature. For example, input chain filters using
*meta skuid*, *meta skgid*, *meta cgroup* or *socket cgroupv2*
expressions are silently accepted but they don't work yet, except when
used with *tproxy* rules, early demultiplexing or BPF programs.
Could you please explain this 'early demux' concept? Is this something
that can be triggered with NFT rules, kernel configuration etc? I can't
find any documentation.
-Topi