Re: How to send nf trace notifications to userspace?

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Sat, Nov 07, 2015 at 12:29:00AM +0100, Florian Westphal wrote:
[...]
> However, the code uses nfnetlink_log.  It appears that its
> unicast only, i.e. its not possible to run another 'nft trace' in parallel
> and also clashes with ulogd or other running logger.
> 
> Thats a non-starter.
> 
> So I'm inclined to toss the nfnetlink_log based changes and
> instead (re-)use the infrastructure that we have for chain, rule, ... notifications.

Something that integrates tightly with the infrastructure is the way
to go. I'd suggest you add a new NFNLGRP_NFTABLES_TRACE nfnetlink
group.

> [...] Also saves us from the 'rule counting' that we're currently
> doing in kernel.

I think we'll have to keep that counting around to provide the legacy
output from the compat layer.

> $ src/nft trace
> SRC=192.168.7.1 DST=192.168.7.10 LEN=88 TTL=64 ID=39366 PROTO=6 SPT=47028 DPT=22 raw prerouting (# handle 6)
> ACCEPT raw prerouting
> filter input (# handle 7)
>         tcp dport ssh jump foo
> filter foo (# handle 5)
>         ip daddr 192.168.7.10
> filter foo (# handle 6)
>         counter packets 912 bytes 63619
> RETURN filter foo
> filter input (# handle 8)
>         ip protocol tcp ip daddr 192.168.7.10
> filter input (# handle 9)
>         tcp dport ssh accept

I guess this is a draft proposal, but I think it would be good to have
a more compact output that can be easily read, eg.

matches: filter input tcp dport ssh accept # handle 9

> Do you think its useful to also dump skb data (i.e. in/outdev,
> packet payload, etc?)

Such information is useful to know what packet is matching what rules.

If we have a way to uniquely identify the packet (probably part of the
skbuff address as we do with conntrack ID from ctnetlink?), we can
just dump this packet data and metadata only once when setting
skb->nf_trace to 1, then from the trace event we only include the
packet ID that results from matching a rule, so userspace can
correlate.

On a different front but related, I think this infrastructure may
allow us to implement the packet path test infrastructure that we
discussed many times before during netfilter workshops at some point.
Kind of similar thing that Rusty made time ago with nfsim.

Thanks for taking over this.