Re: [PATCH nf-next 3/6] netfilter: nf_tables: disable old tracing if listener is present

[Patrick McHardy <kaber@trash.net>]

On 25.11, Jan Engelhardt wrote:
> 
> On Wednesday 2015-11-25 16:06, Patrick McHardy wrote:
> >
> >trace id 85898000 ip ip length 60 ip id 220 ip ttl 64 ip protocol tcp ip saddr 192.168.122.1 ip daddr 192.168.122.84 tcp sport 39558 tcp dport 10000 iif ens3 
> >[...]
> >The second part is the we output normal nft expressions, so "ip" is repeated
> >for every header field. [...] the upside is that the expressions can be
> >easily copy and pasted into the ruleset if necessary.
> 
> "ip ip" looks a bit of out of place. To illustrate,
> 
> 	ip && ip.length==60 && ip.id==220 && ...
> 
> is what the rule seems to mean. However, it is also conceivable that
> someone (who does not have the full knowledge as the .y parser does)
> will read it as
> 
> 	ip.ip.length==60 && ip.id==220 ...
> 
> and might wonder if that is some magic sauce to test the inside header of an
> IPIP packet. Altogether, this causes the nft syntax to remain more confusing
> than the classic iptables one where the &&-segmentation points are reasonably
> known.

Its WIP output. It's supposed to read "ip packet", but I agree, I will
certainly not leave it like this.

> >trace id 85898200 arp filter input verdict 1 mark 0x00000001 iif ens3
> >
> >Comments welcome, especially regarding the current limitations we have.
> 
> I do not think that the far-right printing of IP addresses in the trace output
> is a big deal. Even the iptables TRACE mechanism ends up showing the IP address
> past column 80:
> 
> [239310.214731] TRACE: mangle:INPUT:policy:1 IN=wl0 OUT=
> MAC=7c:7a:91:30:84:cd:18:83:bf:2d:7e:20:08:00 SRC=46.4.122.207
> DST=192.168.217.18 LEN=88 TOS=0x00 PREC=0x00 TTL=56 ID=42841 DF PROTO=TCP
> SPT=22 DPT=34572 SEQ=1941015595 ACK=2361189253 WINDOW=1382 RES=0x00 ACK PSH
> URGP=0 OPT (0101080A0B6162F1038FDA1F) UID=25121 GID=100 
> 
> (add syslog timestamps in front for added effect).
> And perhaps, to a particular reader, the L4 information - which is even
> more right-shifted in both ipt and nft trace - may be more important
> than the L3 part.
> 
> What I think is a doable way is to output the rule in evaluation order -
> basically, the way it was input.
> If the IP TTL is not that important, perhaps that expression should
> have been moved "to the back" when the rule was generated by the
> userspace tool before being entered into the kernel.

Its a decoded packet dump, not the rule. The rule is of course output in
evaluation order.