Hi Daniel,
>> However, it only supprt appending/inserting such match rule. I will not
>> implementing atomic deletion on that one for 1 reason:
>> - current need of match support is only for session, and since each session
>> owns its own chain, it's easier to just flush the chain totally
>>
>> if not convicing enough I have other reasons ;)
> Lets see if we can work around this :)
>
I take it as being curious about the other reasons ;)
The other reason is that atomic rule deletion was mainly due to the case
if connman has to work on iptables when some other components have be
playing also with it, and also in the case of inserting/removing jump
for session's chains into connman's chain. Let's figure it out.
The best example is:
Input:
some rule 1
some rule 2
some rule 3
return DROP
Here you don't want connman to mess with these existing rules (however:
this is a rare case, connman should be the only only playing around with
iptables, on a netbook, desktop, tablets ...)
So the idea is to create a connman specific chain, and inserting a jump
rule like that:
Input:
jump to connman_chain
some rule 1
some rule 2
some rule 3
return DROP
connman_chain:
some connman's rule here
return
Of course, when quitting connman, connman_chain gets flushed, but we
cannot do the same for input: here is the point of atomic deletion: we
just remove "jump to connman_chain". And we remove connman_chain then.
For sessions I see the stuff like that:
connman_chain:
jump to session_1_chain
jump to session_2_chain
some connman's rule here
return
session_1_chain:
match rule for stats
return
session_2_chain:
match rule for stats
return
Here, no need to delete atomically when removing a session's rules. Just
flush it. Only the jump to session's chains needs an atomic deletion.
The other reason is: deletion of a match rule means quite much code. And
according to what I said previously, I don't think it is worthy to get
it implemented into connman (moreover regarding the chain/rule handling
strategy I exposed).
Also afaik, each change on iptables rules means a full reload of rules
in kernel side, so we really want to do as less atomic changes as possible.
iptables API currently needs maybe one only stuff still: changing the
return's policy of a standard chain (Input, output...), so that we can
change to DROP the return's policy of INPUT for instance. This is a
mandatory feature.
I will then move to the firewall feature, at least the basics.
Cheers,
Tomasz
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
