Patrick McHardy <kaber@xxxxxxxxx> wrote:
> On 24.11, Pablo Neira Ayuso wrote:
> > What I'm trying to avoid is the initial race that we'll have.
> >
> > I mean, with this approach the user will likely enable the tracing
> > from the rule, then will launch nft trace. In that case, he will be
> > getting traces from the old way for a little while until you get one
> > process subscribed to this.
Right, not nice.
> On more thing to consider it interaction with other netfilter subsystems.
>
> F.i. I think it would be very useful to have per connection tracing, so
> we'd store a flag in the nfct and transfer it to every packet. This would
> make them show up in the nft ruleset,
I'd prefer to complete set support for labels for this, so we can do
something like
chain ct_trace {
type filter hook prerouting priority 0;
tcp dport 22 ct state new label set trace
ct label trace meta set nftrace 1
}
chain ct_trace_out {
type filter hook output priority 0;
ct label trace meta set nftrace 1
}
Which would do in/out tracing without any additional code
(except the label set support, of course).
> but what about tracing in specific
> points of conntrack/NAT itself? Can we send them to the same group and
> make them integrate with ruleset tracing?
Good point.
I think we would first have to identify possible interesting tracing points.
Did you have anything specific in mind?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
