Open igsilya opened 8 months ago
Thanks for the suggestion Ilya, I think we discussed something similar when we were working on the ct
module.
IMHO, what we should avoid is another filtering syntax for ct events or unfiltered events.
At the time, I looked and I don't remember finding any nf_conntrack tracepoint so we could:
kprobe:ctnetlink_conntrack_event
and hope it doesn't change too much.
I'm not sure if this is even possible as I didn't look into implementation of the CT reporting, but would be nice to see evicted CT entries when passing a packet through conntrack is causing it. It's a little bit of a niche use case, but I was debugging it the other day and it wasn't clear from the retis alone what is happening. So, I had two options: bisect the kernel or crowd-source the answer in hope that other people can give me a clue. Context: https://mail.openvswitch.org/pipermail/ovs-dev/2024-March/412183.html
Example:
This is a new kernel behavior introduced in https://lore.kernel.org/netdev/20230626064749.75525-7-pablo@netfilter.org/ . AFAIU, retis just prints out the ct entry attached to the skb. But it would be nice to capture the moment the old CT entry is evicted because of the packet we're tracing right now.
Maybe just having CT events in general in the trace would be helpful, even if they are not related to the currently tracked packet, as long as they do not obscure the output too much, e.g. by subscribing to events via a netlink group or some kernel probes if there are any.