Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > No, I meant more intrusive version: > > > > ct = nf_ct_get(...); > > if (!ct || nf_ct_is_template(ct)))) > > nf_conntrack_in(net, info->pf, hook, skb); > > OK, then we have to defrag first. Let me give another twist to this > discussion, still brainstorming. No, nf_conntrack forces a dependency on the defrag module, so unless someone inserts such rule before the defrag hook we're fine (raw table prio is fine for instance). > Did you consider to move this logic into a explicit 'track' statement. Yes, but that doesn't help a lot imo since that forces a user to structure ruleset so that they do ct zone set meta mark track with helper "ftp-standalone" which looks fine but what does the 'track' keyword provide? Would a user care? Or is that just more about exposing whats going on behind the scenes? > Instead of this implicit lookup hidden in the helper/timeout > assignment, syntax would be something like: > > tcp dport 21 track with helper "ftp-standalone" timeout "tcp-short-timeout" > > Note, that: > > track with helper "ftp-standalone" timeout "tcp-short-timeout" > > performs this lookup&change as you need, but in one go, only for > unconfirmed conntrack. And this would be achieved with one single > kernel expression, in nft --debug=netlink representation: > > [ track helper "ftp-standalone" timeout "tcp-short-timeout" ] I see, so we add a new expression instead of using ct set syntax. > For zone ID, we can use the same thing: > > track with zone 1 [ This can be combined with helper/timeouts too. ] Hmm.... So we really have comeptely new user syntax for all of this. The reason I scrapped this idea early on is that this breaks horribly with icmp error messages and reply traffic (at very least, its highly counter-intuitive/inconvenient). Consider this fine looking but non-working line: tcp dport 21 track with helper "ftp-standalone" zone 1 instead, users would have to do this: track with zone 1 # so icmp, reply traffic, ftp data traffic is in zone 1 too tcp dport 21 track with helper "ftp-standalone" and that won't work either since we would have to support 're-tracking' already tracked conntrack... I planned to force explicit 'track' for the bridge conntrack support, but that works only because the nf_conntrack_in PREROUTING equivalent added in bridge_conntrack would not ever create new conntracks (only RELATED). We can do this because there is no bridge conntrack so far so we don't have backwards compat problems. But then I thought 'why add special "track" if I can just let ct foo set bla do it for me'? > In this case, we pass the zone ID via nf_conntrack_in() [ or a new > function that is called from nf_conntrack_in() that takes the zone ID > and that doesn't depend on templates anymore, we can strip off > nf_conntrack_in() from the template logic ]. I found no way to avoid templates for the zone because of the RELATED packets. > > > Back to helpers, users are familiar with the current way to attach > > > helpers, ie. from the raw chain. > > > > > > Am I missing anything? I'm starting to think we can't escape the > > > conntrack template. > > > > For Helpers? Why not? As long as ct isn't in the main table it should > > be fine afaics? (Unless you mean "can't escape conntrack template to > > read to helper info that we need to assign to ct from". > > > > For zones, yes, I don't see a way to avoid a template for them. > > But thats the only ct key where I think that a template has to be used. > > Yes, following the approach you propose zone would be the only one > that requires the template. So this needs to happen before the > conntrack hook. Yes, thats 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
