> 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.
Notify a kernel module that the firewall configuration has changed. The user script is called only when the firewall is restarted - why is that? On Mon, Dec 15, 2014 at 8:39 PM, Steven Barth <cy...@openwrt.org> wrote: > >> 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 <cy...@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" <cy...@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@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
