On 26 October 2016 at 20:50, James Feeney <james@xxxxxxxxxxx> wrote:
>> I can't reproduce the issue here.
>
> Thanks Arturo. What distribution are you using? Hmm - any suggestions about
> how to "poke" at this issue on my end?
>
I'm using Debian, of course :-)
You could check the config of your kernel. That error message seems to
come from the kernel.
Perhaps, the reject modules were not configured.
Please, check NF_TABLES* and NFT_* symbols (also NF_*)
For the record, the debian kernel 4.7.0 contains:
% egrep NF_TABLES\|NFT_\|NF_ /boot/config-$(uname -r) | grep -i reject
CONFIG_NFT_REJECT=m
CONFIG_NFT_REJECT_INET=m
CONFIG_NFT_REJECT_IPV4=m
CONFIG_NF_REJECT_IPV4=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_NFT_REJECT_IPV6=m
CONFIG_NF_REJECT_IPV6=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_NFT_BRIDGE_REJECT=m
> BTW, I can load this file without problem when replacing "reject" with "drop".
> Whatever the problem, it is "triggered" by the "reject" statement.
>
> I was concerned that perhaps my system was in some inconsistent upgrade state,
> because I noticed I was actually still running kernel 4.8.1-1, not 4.8.4-1.
>
Using a newer kernel is always a good idea. Newer ones will contain
up-to-date code, fixes.
So yes, some behaviour may have changed between 4.8.1 and 4.8.4.
>
> /etc/test.nft:4:1-2: Error: Could not process rule: Operation not supported
> table ip private {
> ^^
>
> Well, that's not good, because something changed, from "No such file or
> directory" to "Operation not supported", but it is still not right. Of course,
> in both cases, the error messages are "useless", not saying *what* file, and not
> saying *what* operation.
>
Yes, the error reporting in the 'nft -f' situation is something to improve,
specially with kernel reported errors.
This is even worse in the case of nested includes.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
