I can't either stop or start nftables because it's initscript has buggy save part. It should probably be rewritten, all tables may be listed using "nft list ruleset" command since Linux Kernel 3.18: http://wiki.nftables.org/wiki-nftables/index.php/Operations_at_ruleset_level The same keyword may be used for flushing. Example of error message: # rc-service nftables stop nftables | * Saving nftables state ... nftables |<cmdline>:1:15-16: Error: syntax error, unexpected ip, expecting string nftables |list table ip ip filter nftables | ^^ nftables |<cmdline>:1:15-16: Error: syntax error, unexpected ip, expecting string nftables |list table ip ip nat nftables | ^^ nftables |<cmdline>:1:16-17: Error: syntax error, unexpected ip, expecting string nftables |list table arp ip filter nftables | ^^ nftables |<cmdline>:1:16-17: Error: syntax error, unexpected ip, expecting string nftables |list table arp ip nat nftables | ^^ nftables |<cmdline>:1:16-17: Error: syntax error, unexpected ip, expecting string nftables |list table ip6 ip filter nftables | ^^ nftables |<cmdline>:1:16-17: Error: syntax error, unexpected ip, expecting string nftables |list table ip6 ip nat nftables | ^^ nftables |<cmdline>:1:19-20: Error: syntax error, unexpected ip, expecting string nftables |list table bridge ip filter ...
Created attachment 412362 [details, diff] nftables init script patch for version 0.5 It's because the behavior of nft list tables <family> and nft list tables changed. They both act the same now and return a list of tables in table <family> <identifier> format. This patch should fix the issue.
(In reply to diamond from comment #0) > I can't either stop or start nftables because it's initscript has buggy save > part. It should probably be rewritten, all tables may be listed using "nft > list ruleset" command since Linux Kernel 3.18: > http://wiki.nftables.org/wiki-nftables/index.php/Operations_at_ruleset_level Admittedly, I didn't know about this option when I wrote the patch; however, as 3.14.48 is still in the portage tree and supports nftables, I'm choosing not to update my patch to use that command so that compatibility is maintained.
Is it possible to add a check to the init script, which will decide by comparing the kernel version which method to use? Or: is it possible to add an additional use flag, which will enable/disable the method to use?
(In reply to bgo from comment #3) > Is it possible to add a check to the init script, which will decide by > comparing the kernel version which method to use? > > Or: is it possible to add an additional use flag, which will enable/disable > the method to use? I could add a kernel version check to the patch and switch to using 'nft list ruleset' for kernels 3.18 or newer. I imagine that would be a better approach than adding a USE flag. However, switching to 'nft list ruleset' won't fix 560206. To fix 560206, the sed hack would have to be removed. However, removing the sed hack now will also reintroduce the bug it was attempting to fix. The only way to fix both of those issues is to file a case upstream and have it fixed there. If no one else files the issue, I'll try to do it later today or tomorrow.
We can also check kernel version in ebuild and install different script versions depending on it. There are also some recommendations on atomic update there which may be useful: https://lists.netfilter.org/pipermail/netfilter-announce/2015/000216.html Wasn't bug #560206 fixed in that paticular version of nftables?
(In reply to diamond from comment #5) > We can also check kernel version in ebuild and install different script Assuming I get a vote, I would like to vote for this idea. If I have the time, I'll submit patches to the ebuild to allow it to choose between init scripts. > versions depending on it. There are also some recommendations on atomic > update there which may be useful: > https://lists.netfilter.org/pipermail/netfilter-announce/2015/000216.html I'm not sure I follow here. Granted the script does not support atomic updates (mainly because the iptables script doesn't), but it does already use 'nft -f' in start() to restore the firewall. > > Wasn't bug #560206 fixed in that paticular version of nftables? Bug #560206 is actually my fault, as I'm the one who wrote the sed substitution (and the explanation for it) into the init script in the first place (see bug #508182 ). At the time, I forgot to file a bug upstream to get the underlying issue fixed. I have remedied that by filing the bug yesterday (http://bugzilla.netfilter.org/show_bug.cgi?id=1032). Once that issue is fixed, the sed substitution shouldn't be needed anymore from that point forward.
Created attachment 412986 [details] Updated init script for users of kernels older then 3.18
Created attachment 412988 [details] Updated init script for users of kernel versions 3.18 or newer
Created attachment 412990 [details] Updated ebuild
I've added a new set of init scripts and an updated ebuild that reflect the recommendations made in comments #1 and #5. I also removed the calls to sed as that will likely fix issue #560206. I don't think many people will hit the scenario that substitution is trying to fix. However, if I'm wrong, an upstream bug report has already been filed. The URL is http://bugzilla.netfilter.org/show_bug.cgi?id=1032 .
Thank you. I've just checked your ebuild and new initscript. They are working fine for me. I think that your old initscript should work too (I've already checked it's old version before, it was ok too). I think it can be merged into portage tree.
Thanks for your help and contribution. I'd rather see the change included in the init-script instead of making a hard decision during install time. A user might switch the kernel back or forward to another version later.
(In reply to Manuel Rüger from comment #12) > Thanks for your help and contribution. > > I'd rather see the change included in the init-script instead of making a > hard decision during install time. A user might switch the kernel back or > forward to another version later. I moved the change into the init script. It makes it a bit more complicated, but I'm hoping I've got it organized in a way that the extra logic can be removed when it's no longer needed. I also liked the nft -f approach to the panic() command over what I had previously done, so I chose to backport that to version 0.4 instead of using the original logic.
Created attachment 413944 [details, diff] nftables-0.5 ebuild panic() patch This patch installs rules-panic into /var/lib/nftables. rules-panic is a predefined rule set that is used in conjunction with /etc/init.d/nftables panic command to stop the nftables service and configure nftables to drop all packets.
Created attachment 413946 [details, diff] nftables-0.4 ebuild panic() patch Same as the nftables-0.5 ebuild panic() patch, but for nftables-0.4.ebuild.
Created attachment 413948 [details] Revised nftables init script
Created attachment 413950 [details] the panic nftables ruleset I'm not completely sure that /var/lib/nftables is the right place for this file, but I can't think of a better place to put it.
Created attachment 413972 [details] IPv4 panic nftables ruleset I'm guessing there's someone who doesn't use a dual stack IP setup. I've adjusted the scripts to handle that case. Unfortunately, this meant breaking the panic ruleset file into two. This is the IPv4 half.
Created attachment 413974 [details] IPv6 panic nftables ruleset The IPv6 half of the panic ruleset
Created attachment 413976 [details] Revised nftables init script I had to rewrite getfamilies() as the original function did not work as intended with 0.4 (nft always exits with status 0 when listing tables).
Created attachment 413978 [details, diff] nftables-0.4. ebuild panic() patch updated for non-Dual Stack setups.
Created attachment 413980 [details, diff] nftables-0.5 ebuild panic() patch updated for non-Dual Stack setups, and I think this fixes everything. Sorry for the extra noise. I'll be more rigorous in my testing in the future.
Thanks for your contribution, nvinson. Are you interested in proxy maintaining nftables? [1] [1] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
(In reply to Manuel Rüger from comment #23) > Thanks for your contribution, nvinson. > Are you interested in proxy maintaining nftables? [1] > > [1] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers I'll be happy to pick it up. I would, however, would prefer to use a different email address than the one I've been using here. Thanks.
(In reply to nvinson from comment #24) > (In reply to Manuel Rüger from comment #23) > > Thanks for your contribution, nvinson. > > Are you interested in proxy maintaining nftables? [1] > > > > [1] https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers > > I'll be happy to pick it up. I would, however, would prefer to use a > different email address than the one I've been using here. > > Thanks. done. Nicholas I will add you as maintainer when this reaches completion. My reading of it is it's not there yet.
Created attachment 414588 [details, diff] new ebuild version based on IRC discussion obsoletes the 0.4 version because that version has been removed from the tree.
Created attachment 414590 [details, diff] and the new init script.
Created attachment 414592 [details, diff] git format patch output
commit 322474a9c7cb65b6ebd39d8efd8526f19c38f90b Author: Ian Delaney <idella4@gentoo.org> Date: Thu Oct 15 17:05:28 2015 +0800 net-firewall/nftables: revbump and patch to fix broken init script patches submitted by Nicholas Vinson via gentoo bug, set in metadata as new proxy maintainer by invitation by developer maintainer mreug, thanks to gokturk for assistance and cross testing Gentoo bug: #560920
