Perhaps see https://github.com/X4BNet/xt_NOCREATE On Mon, 23 Aug 2021 at 23:31, Eugene Crosser <crosser@xxxxxxxxxxx> wrote: > > On 19/08/2021 16:18, Florian Westphal wrote: > > Eugene Crosser <crosser@xxxxxxxxxxx> wrote: > ... > >>>> Yet I am surprised that a flag meaning "conntrack, but only to confirm exiting > >>>> entries" does not exist. Would not it be useful to have?.. > >>> > >>> How would that even work? > >>> > >>> To know if a given packet is a reply there needs to be a record in the > >>> state table. > >> > >> I was guessing this piece of code > >> > >> ===== > >> /* look for tuple match */ > >> zone = nf_ct_zone_tmpl(tmpl, skb, &tmp); > >> hash = hash_conntrack_raw(&tuple, state->net); > >> h = __nf_conntrack_find_get(state->net, zone, &tuple, hash); > >> if (!h) { > >> h = init_conntrack(state->net, tmpl, &tuple, > >> skb, dataoff, hash); > >> if (!h) > >> return 0; > >> if (IS_ERR(h)) > >> return PTR_ERR(h); > >> } > >> ct = nf_ct_tuplehash_to_ctrack(h); > >> ===== > >> > >> could _not_ call `init_conntrack()` depending on the (hypothetical) "track only > >> when entry exists" flag, and return early otherwise?.. But my understanding of > >> the workings of netfilter is really poor, it is very likely that I am missing > >> something crucial. > > > > I don't see how it can work, something does need to create entries, else > > __nf_conntrack_find_get() never finds an entry, so init_conntrack() is > > never called, so table is always empty. > > I was (probably incorrectly?) assuming that __nf_conntrack_find_get() looks up > in the "main" table, so there will be entries created by previous packets that > went "in the opposite direction" and did not have the "track only when entry > exists" flag. In my case, packets that have traversed the OUTPUT chain. > > By the way, another way to implement such feature would be a settable flag in > the skb "do not commit to the main conntrack table"?.. > > I need to check how "fib daddr type local" will work in the presence of VRFs > that may be forwarding the same addresses that in the default VRF are going to > INPUT. Basing decision on the input interface is kind of undesirable for us, > because there are so many, and some may be named differently on different hardware. > > >> While I am here, may I ask: is there a "correct" way to re-enable conntrack that > >> was disabled in someone else's chain that happened to run before mine? > > > > You mean, 'cancelling' earlier NOTRACK rule? I'm not aware of such a > > feature. > > That's what I thought. That means that different entities that need to control > `notrack` cannot pile up "exceptions on top of exceptions" and have to cooperate > very stringently. If I want to have a chain that ends with unconditional > catch-all "notrack", then everyone who needs to enable tracking for a specific > class of traffic must have rules in the same chain. But we can work with that. > > Eugene >
