Hi Tomasz, On Tue, Oct 25, 2011 at 08:57:31AM +0300, Tomasz Bursztyka wrote: > 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 ...) Yes, and anyone running ConnMan on e.g. a server should keep in mind that it was not designed for that.
> 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 I'm ok with having our own connman chain, although this won't solve any of the iptables existing race conditions. > 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. Atomic operations is impossible with the current iptables API. Even if you have your own chain you could still easily hit race conditions whenever someone is modifying your table before you commited your chain or jump deletion. As soon as you assume that several processes are playing with the same table, you're lost. So here we just don't have any answer to the case where ConnMan runs and modifies your system iptables together with other processes. If ConnMan is managing your network, it should be the only one messing with iptables. > Also afaik, each change on iptables rules means a full reload of rules > in kernel side, That's correct. Simply because you push the entire table every time. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
