On 25.11, Jan Engelhardt wrote: > > On Wednesday 2015-11-25 17:53, Patrick McHardy wrote: > >> > >> 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. > > Would it be possible to make the program which receives the trace over > netlink to take a command-line argument or a filename that specifies > which expressions to preferentially order to the left? > Something like > > trace --fields=ip.saddr,ip.daddr,tcp.dport,ip.ttl,* > > (the ,* part being implicit if omitted) It sounds like an interesting idea, especially if we omit fields be default. Let's see: I defintely don't want to add new lexing and grammar rules for all the protocols, so the syntax would have to be based on the current expressions. So it would likely not be a command line option but something which is handled by the parser: nft monitor trace decode ip saddr, ip daddr, tcp dport, tcp sequence, * That should be easy to integrate. Next question would be how to deal with unspecified protocols or how to specify preferences for multiple protocols at once. In many address families and on higher layers we normally don't know what kind of packets we will receive. It might be preferrable to have an abstract way to specify the fields of interest, but I'm unable to think of something reasonable. We might be able to do some grouping, f.i. "l3proto identity" for source and destination address of any L3 protocol, but many fields are hard to group. Alternatively we can of course always apply the default encoding and simply allow to override it for one specific packet type, like ether + ip + tcp. Suggestions are welcome. -- 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
