On Wed, Jun 14, 2017 at 01:53:38PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > The extra hook has a performance impact though, is it something that > > would just go away one x_tables is gone? What is your plan on this? > > Once we do it we can't remove it again, because you can have multiple > nat base chains after this change, and removing hook and merging it back > into the l3 nat code means first chain attaches a null binding again. With multiple nat chains, in case of overlap, we would just take the last coming in the pipeline. Just like several chains several times the same packet from a filter chain, right? > > On a different front (just an idea), I would really like to provide an > > alternative to setting conntrack templates, so we can get rid of > > having a chain (hence another hook) just to set the zone. It's just > > more cycles on a hook to do something very simple. > > I don't think it can be done, the zone id has to be set before conntrack > lookup, I see no way to avoid this? > > So even if we find a way to transport zone id from one hook to the > next (sans skb->nfct template) we still need one extra hook to > configure/set the zone id to use. Can we do this from rule? So we run sort of nf_conntrack_in() from a expression that enables tracking? I remember you mentioned about ICMP and related traffic, we just have to document how to configure this so people don't shoot on the feet, ie. track both tcp and icmp if you want to do this right with this selective tracking expressed in positive logic (contrary to the notrack, negative, logic). I guess you would need something like this for bridge conntrack support, right? -- 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
