On 2021/03/09 16:06, Pablo Neira Ayuso wrote:
On Tue, Mar 09, 2021 at 06:24:28PM +0100, 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.
Just posted a patchset, maybe we can address this inconsistency moving
forward:
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210309210134.13620-2-pablo@xxxxxxxxxxxxx/
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210309210134.13620-3-pablo@xxxxxxxxxxxxx/
Cool! Thanks!!!
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.
Actually it can be place in forward chain too IIRC.
If the rule is added to prerouting, then the ct helper is attached to
both input and forward traffic.
Thanks - I will add to the wiki page.
Best Wishes,
Frank
