Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021/03/09 12:24, Florian Westphal wrote:
Frank Myhr <fmyhr@xxxxxxxxxxx> wrote:
1) I will look at the code, but am surprised that "ct helper" uses the
in-kernel name "ftp" rather than that of the stateful object "ftp-21" that
the ruleset goes to the trouble of explicitly defining.

a) Is this simply a parsing artifact -- if the helper were called "abcd"
would the expression 'ct helper "abcd"' match it?

b) If it is NOT a parsing artifact but by design: why? It would be more
intuitive to use the name of the explicitly-named helper object. Another way
to ask the same thing: why bother with the explicit helper object at all,
rather than just use "ftp" (which implies the ip & tcp protocols in "ftp-21"
definition anyway) in both match and statement, like 'ct helper set "ftp"'?

Its a design fuckup.  When I made the objref patches to attach the
defined helpers I did not consider that we already had a 'ct helper'
with existing behaviour.

The explicit helper objects were done this way to allow defining
multiple helpers wuth different settings.

There are helpers that can be tuned by options and users might want to
use different settings in each.

Got it. Thank you for very much for explaining the history and rationale.


2) Does it make a difference whether 'ct helper set' is done in input (as in
below ruleset) or in prerouting? Maybe it has to be in prerouting only in
case of forwarded traffic?

It can be in input if the traffic is not forwarded.

Thanks for confirming. I'll make the wiki page more explicit on this point.

Best Wishes,
Frank



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux