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 _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
