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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
