On 02/22/2016 11:39 AM, Daniel Mack wrote:
On 02/22/2016 11:04 AM, Daniel Wagner wrote:
> On 02/22/2016 09:54 AM, Tomasz Bursztyka wrote:
>> I haven't been following the recent (well... the last ~2 years ^^')
>> work on nftables but I believe there are still people using the
>> iptables format. The use the iptables- nftables compatible tool, and
>> it mimics iptables through nftables. Verify it, but if it's the
>> generic way, then it would be as usual in ConnMan.
It aims for that, yes, but in my tests there were quite some uncovered
corner cases when it comes to command line compatibility. But I wonder
why this is related to ConnMan - does it call out to the binary?
We are using libxtables direcly which is a huge pain as it was never
design to be used as we do it. We didn't want to call iptables via shell
all the time.
>> If not, then you will have to come with a strategy that fits
>> that's when it
>> might become tricky. As you noticed, ConnMan will have to avoid conflicts.
I haven't followed the discussions. What kind of conflicts is this about?
For iptables, we are maintaining our own input and output chain and
insert into the main chain. And than we hope no one is killing the
chain. It gets tricky after crash or restart to sync up correctly.
In short we toetipping around trying to avoid to mess with other
>> I believe it will be a bit easier than with iptables though.
>> - you pull the current context:
>> -> if there is nothing, it will be easy ConnMan will just push
>> whatever it will want.
>> -> if something is there, integrating will have to play nice.
>> Basically: finding the
>> input entry point to jump on a custom ConnMan table (you'll probably
>> need that
>> for each IP version), get you rules applied or return if nothing.
IMO, ConnMan, or any other tool for that matter, should never mess with
rules it hasn't created itself.
Yes, completely agree.
nftables makes this easy, as it allows
for namespaces in the rule sets, through custom tables.
Ah, so that sounds like I was looking. This is the answer to my initial
If any other
tool installs other tables with conflicting rules, I don't think ConnMan
should care really.
That is the plan.
With iptables, this is just a bit trickier due to
the custom jump label that you have to install in the INPUT and OUTPUT
Right now, there are two parts of systemd that touch packet filter
configurations, nspawn and networkd, and the code already takes care of
not touching any rule that it has no business with.
> Lennart posted the headsup on systemd moving from iptables to
> nftables . I don't know how far those plans have gotten but I think
> it would be good idea to coordinate this with systemd-networkd.
> @Tom do you happen to know what the status is on this?
It was me who worked on this, and I postponed the branch a while ago
until we know how the kernel APIs look like that we want to use for a
per-unit packet filtering mechanism. Back then, it looked like this
could only be achieved with nftables, which is why I reworked all the
code in systemd.
Ah, I though Tom was working on this. Sorry about that.
Now, things are not that clear anymore, so the decision was
hope to catch up with this soon, but eventually, I think we should move
to nftables as well. Note, however, that iptables and nftables may
coexist on a system.
My hope is that if ConnMan just uses nftables, the kernel needs to sort
out the problems. I know I live in a naive world. :)
>> About coding around, it's a bit messy. There is one
>> libnftnl. It's not build on top of libnl. I am not entirely sure, but
>> I think you can hook your own netlink access functions to it. By
>> default it uses libmnl... You'll have to verify that. Ask Marcel what
>> he would prefer as well. Afaik, there is still the plan to move
>> ConnMan to ell, so keeping it's custom netlink access would make
>> sense then, I guess.
> I really like to avoid coding directly netlink. The libnftnl doesn't look
> too bad.
You can have a look at the outdated branch of mine here:
Thanks for the pointer.