| Summary: | net-firewall/nftables: rules are saved with numeric values which break in some cases | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ogelpre <gentoo.org> |
| Component: | Current packages | Assignee: | Matthew Thode ( prometheanfire ) <prometheanfire> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | base-system, Ikonta, kfm, klondike, prometheanfire |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://git.netfilter.org/nftables/commit/?id=1ab1fcbc19a82e03d229586b8fd5b16396a9fab7 | ||
| See Also: |
https://bugzilla.netfilter.org/show_bug.cgi?id=1555 https://github.com/gentoo/gentoo/pull/21795 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
This seems to be an upstream bug. We could try using "-T -y -p" instead to prevent the issue, but I suspect nft should be able to load rules saved using -n. Checking the YAML description it says it expects a string though. Using "-T -y -p" as workaround works for me. I have backported Pablo's patch instead to 0.9.9 (which is a better solution). Had to make a new Pull Request instead. This change will be on the next release too, so for my side it may be valid to close it as resolved upstream and wait for the next release. Keep in mind that the first commit in my PR still needs to be applied nevertheless. Closing as RESOLVED because the issue was addressed by nftables-1.0.0, with 1.0.5 being the earliest version now available in the gentoo repo. |
The nftables scripts uses SAVE_OPTIONS="-n". This breaks rule loading in some cases. Reproducible: Always Steps to Reproduce: Add the following rule: nft add rule inet filter input reject with icmpx type admin-prohibited Save it with /etc/init.d/nftables save and try to load the saved ruleset. Actual Results: /var/lib/nftables/rules-save:5:26-26: Error: syntax error, unexpected number, expecting string reject with icmpx type 3 Expected Results: Rules should be loaded. I don't know if this is a upstream bug or if the behavior is expected. I suppose to remove the -n flag from SAVE_OPTIONS for now. Alternatively we can add a hint to the default config that remove -n can avoid this problem.