[OpenWrt-Devel] nftables development and support in openwrt

[Steven Barth]

> You are right. I asked it in the netfilter-devel mailing list -
> libipct was never meant to be used as a public interface:
> http://www.netfilter.org/documentation/FAQ/netfilter-faq-4.html#ss4.5
Meh, absent of anything else it de-facto is anyway, see e.g. squid, 
miniupnpd and others using it as well.

>
>> Also at the moment its not very clear when the netfilter team will create a high-level library to interact with
>> nftables which would probably be sort of a prerequisite for it depending on how this rewritten daemon
>> will work.
> I'm not sure if such a "high level library" is planned by the
> netfilter team, but why isn't libnftnl sufficient for rewriting the
> openwrt firewall daemon?
I've seen a high-level library being mentioned in some nftables 
presentations, e.g. 
https://home.regit.org/wp-content/uploads/2014/09/2014_kernel_recipes_nftables.pdf

The problem is this: libnftnl only allows manipulating nftables tables 
etc. but doesn't help with generating BPF-bytecode of the actual rules. 
This is done by the nftables-binary but not in a library. Generating 
that BPF-code is the actual hard part here and using libnftnl directly 
would mean we would have to do that on our own thus actually 
reimplementing the stuff that the nftables binary does.

Another option would be to generate an nftables rule-file and "applying" 
this by calling the nftables binary, not exactly that trivial and / or 
clean either.



>
> Back to original problem of adding iptables rules awareness to kernel modules -
> I think that until nftables is fully supported in openwrt, it is
> possible to either patch the firewall package or libipct to notify
> about rules changes. Can such a change be acceptable in formal
> release?
Notify whom? I mean we could probably notify someone or something when 
the high-level openwrt firewall is reloaded. In fact there is already a 
user-script hook.



Cheers,

Steven

>
> Best Regards,
>
> Tomer
>
> On Mon, Dec 15, 2014 at 9:18 AM, Steven Barth <cyrus at openwrt.org> wrote:
>> Hi Tomer,
>>
>>
>> Regarding the firewall package - its probably a dumb question, but isn't
>> this the reason for nftables' compatibility layer?
>> (http://git.netfilter.org/iptables-nftables/)
>>
>> afaik - and please correct me if I'm wrong - that works only for the
>> iptables CLI command, however our firewall tool currently uses libiptables
>> directly so I don't think it would work easily.
>>
>>
>> Cheers,
>>
>> Steven
>>
>>
>> Best Regards,
>>
>> Tomer
>>
>> On Dec 14, 2014 7:08 PM, "Steven Barth" <cyrus at openwrt.org> wrote:
>>>
>>> Hi Tomer,
>>>
>>>> I am currently working on a kernel module which offloads traffic from the
>>>> Networking stack.
>>>> This is part of a project which optimizes IP forwarding for low end
>>>> routers that have weak CPU and low on memory.
>>> Sounds interesting. Other approaches of speeding up forwarding are btw.
>>> also investigated right now, see https://dev.openwrt.org/changeset/43587
>>>
>>>>
>>>> I saw that nftables and libnftables are not yet supported in my openwrt
>>>> codebase (I am working with attitude adjustment 14.07)
>>> there is no attitude adjustment 14.07. attitude adjustment is 12.09,
>>> barrier breaker is 14.07.
>>>
>>>
>>>> - but saw that recently some nftables related patches were added to the
>>>> master branch by you.
>>>> Could you please share the current status of nftables support in openwrt?
>>> nftables is packaged, I added some patches so that it is a bit more
>>> embedded friendly (some of those are upstream, some of them aren't). I also
>>> packaged and reorganised the netfilter kernel packages.
>>>
>>> So you can select nftables in menuconfig and can play around with it. You
>>> can also get rid of iptables and use nftables only by deselecting the
>>> related packages.
>>>
>>>
>>> Known Issues
>>> * In general its not well tested. It might blow up here or there. Help and
>>> bugreports are appreciated.
>>>
>>> * We are aiming for kernel 3.14 for the next release which has somewhat
>>> reasonable nftables support but lacks some useful things e.g. devgroups,
>>> extended reject support among maybe other things iirc. So it will be there
>>> to play around / get a first look at it but thats it. I don't know how the
>>> following release will look but I wouldn't keep my hopes up all too high
>>> there for it to change that much.
>>>
>>> * Which brings us to the main issue, our firewall abstraction (the
>>> firewall package, all the /etc/config/firewall magic) is tied to iptables at
>>> the moment, so if you want to use nftables right now you get bare metal and
>>> have to write your own rulesets completely from scratch, cannot use
>>> /etc/config/firewall or a gui.
>>> Hopefully someone will put some effort into this next year and refactor
>>> our firewall daemon to use nftables but thats a major effort. Also at the
>>> moment its not very clear when the netfilter team will create a high-level
>>> library to interact with nftables which would probably be sort of a
>>> prerequisite for it depending on how this rewritten daemon will work.
>>>
>>>> Regardless, I will be happy to participate with the development and
>>>> testing of nftables if needed, just let me know if I can help,
>>> Feel free to play around with it and send me bugreports etc.
>>>
>>> If it looks like an nftables bug you should probably contact the netfilter
>>> guys directly. If it looks like I messed up a patch or a package definition
>>> then tell me.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Steven
>>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel