[systemd-devel] nftables

Daniel Wagner daniel.wagner at bmw-carit.de
Mon Feb 22 10:04:19 UTC 2016


Hi Tomasz and Tom,

On 02/22/2016 09:54 AM, Tomasz Bursztyka wrote:
>> Hi Tomasz,
>>
>> I just chatted with Patrik and told him about my idea to teach ConnMan
>> to use nftables instead iptables. There are a few things to figure out
>> first though.
>>
>> If I got that right there is no policy from the kernel on how to
>> structure the rule sets. nat/filter tables and input/forward/output
>> chains are userland policies. The question is how would ConnMan fit into
>> this? As you know, ConnMan tries to avoid conflicts with iptables in tip
>> toeing around. Do we have to do the same with nftables?
>
> You are right, when you start bare metal kernel with nftables: there
> is nothing. No tables and no chains. It's a good thing because it
> enables flexibility, but it can also be a burden when it comes to
> integrate with custom table & chains.

Okay, so nothing new :)

> 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.
> 
> If not, then you will have to come with a strategy that fits all. And
> that's when it
> might become tricky. As you noticed, ConnMan will have to avoid conflicts.
> 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.
>
> Problem start to arise when somebody/something else messes up again
> with the context. Like flushing out everything, reinstalling stuff...
> ConnMan will have to follow. It was the same with iptables. It's
> hopefully much easier now: there are proper netlink notification
> messages for it. Well, let's put this problem apart for now.

Lennart posted the headsup on systemd moving from iptables to
nftables [1]. 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?
 
> About coding around, it's a bit messy. There is one library,
> 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. 

cheers,
daniel

[1] https://lists.freedesktop.org/archives/systemd-devel/2015-May/032531.html


More information about the systemd-devel mailing list