Le 01/03/2013 14:19, Patrik Flykt a écrit :
On Fri, 2013-03-01 at 11:19 +0100, Daniel Wagner wrote:
I don't follow here. I have the managed_hooknames[] table for this
(patch 13). The rest of the code should just use this table unless I
missed something.
iptables.c needs to provide manipulation only for the exact names given
as is now before this patch set. iptables.c is complex enough, so it
should not translate from one set of names to another set of names.
iptables.c is the low-level api which sets rules without any questions
asked.
Then there exists higher-level functionality such as enable_nat(), which
is given a set of nat parameters. Or the session iptctx helpers in your
other patch set that have a few parameters for multiple routing setup
and firewall marking etc. These are the logical places where high-level
functionality is given as input.
What is missing is a translation layer in between. If we consider status
quo, nat.c is the only place currently setting up any of these rules.
Therefore it would be logical to have enable_nat() to 1) create the
connman specific nat chain and anchor it to the builtin if it didn't
exist and 2) add the needed rule to the connman specific nat chain. Both
part 1) and 2) would use the proper functions from iptables.c, where
iptables.c would not do any translation whatsoever. Needless to say, as
more functionality is added, part 1) is a definite candidate to be
factored out in it's own file. As well as part 2), because it belongs to
the same functionality family as 1) in a dedicated file. What I don't
want is an implicit translation from "OUTPUT" to "connman-output" in
iptables.c, after that we're all confused of what is going on.
1- nat.c __connman_whatever_append_rule(nat, POSTROUTING, rule_spec)
2 --> whatever.c: Translate POSTROUTING to connman-POSTROUTING
Does what's necessary in case of non existing
connman-POSTROUTING.
Same for connman own table etc...
Then calls -> __connman_iptables_append(connman_table,
connman_chain, rule_spec)
Would be the same for ipt context, it would use this in-between layer.
When starting connman would call __connman_whatever_flush()
So we keep existing code of iptables.c as it is.
Let's find a name for whatever.c (firewall.c, filter.c ? )
Tomasz
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
