reject statement - "crazy" parse error?

reject statement - "crazy" parse error?

[James Feeney]

Arch Linux
linux 4.8.4-1

nftables-git 0.6.r96.gbb636b8-1
libnftnl-git 1.0.6.r68.gc26951e-1


/etc/nftables.conf

flush ruleset
define if_WAN = enp3s0

table ip private {
 chain postroute {
  type filter hook postrouting priority 0;
    oifname $if_WAN ip daddr 192.168.0.0/16 reject
 }
}

$ sudo nft -f /etc/nftables.conf
/etc/nftables.conf:4:1-2: Error: Could not process rule: No such file or directory
table ip private {
^^

I'm guessing that that error message is wildly off-base.

Or is "reject" not a proper "terminal statement"?

Or is there something wrong with the syntax?

Re: reject statement - "crazy" parse error?

[Arturo Borrero Gonzalez]

On 26 October 2016 at 03:30, James Feeney <james@nurealm.net> wrote:
>
> I'm guessing that that error message is wildly off-base.
>
> Or is "reject" not a proper "terminal statement"?
>
> Or is there something wrong with the syntax?

I can't reproduce the issue here.

% nft -f test.nft
% nft list ruleset
table ip private {
   chain postroute {
      type filter hook postrouting priority 0; policy accept;
      oifname "enp3s0" ip daddr 192.168.0.0/16 reject
   }
}

Re: reject statement - "crazy" parse error?

[James Feeney]

> 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?

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.

I tried a reboot and recompiled
nftables-git 0.6.r96.gbb636b8-1
libnftnl-git 1.0.6.r68.gc26951e-1

And now, I get this:

/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.

I also tried re-installing the stock
libnftnl   1.0.6-1
nftables  1:0.6-2

Those give the same error message.

Should the linux kernel have any effect on this error?

I noticed there is some debugging support in nft.  The error message is
displayed last with debug scanner or parser, and displayed first with debug
eval.  With debug mnl, the error is displayed in the midst of the output.

Hmm - any thoughts?

Re: reject statement - "crazy" parse error?

[Arturo Borrero Gonzalez]

On 26 October 2016 at 20:50, James Feeney <james@nurealm.net> 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.

Re: reject statement - "crazy" parse error?

[Pablo Neira Ayuso]

On Fri, Oct 28, 2016 at 11:07:24AM +0200, Arturo Borrero Gonzalez wrote:
> On 26 October 2016 at 20:50, James Feeney <james@nurealm.net> wrote:
[...]
> > 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.

Just for the record: I have a patch to solve this. We need to augment
the netlink error reporting infrastructure, if I add this into the
netlink core (which is where this improved error reporting
infrastructure belongs) it may take a little while though, and a bit
of code in userspace.

Re: reject statement - "crazy" parse error?

[James Feeney]

Thanks Arturo

> I'm using Debian, of course :-)

I see that Debian Sid has kernel 4.7.8-1, where Arch is at kernel 4.8.4-1.  So I
tried loading the test.nft on a machine running the Arch lts kernel, 4.4.27-1.
It loaded without any problem.

At this point, I will infer that nftables-0.6 or libnftnl 1.0.6 is not playing
well with linux 4.8, where there seems to be a problem on both 4.8.1 and 4.8.4,
but not on 4.4.27 or 4.7.8.

Is there any way you could try loading test.nft with a recent 4.8 kernel?

> You could check the config of your kernel. That error message seems to
> come from the kernel.

That makes sense, since this issue seems to track with kernel version.

> Please, check NF_TABLES* and NFT_* symbols (also NF_*)

No problem there.  Those modules are all enabled.

> Yes, the error reporting in the 'nft -f' situation is something to improve,
> specially with kernel reported errors.

Assuming this issue is something to do with linux kernel interaction, any
suggestion about where to look next?  Has the kernel changed the nft_reject
sysfs interface?

Re: reject statement - "crazy" parse error?

[James Feeney]

Hmm - something else I just noticed, with test.nft as the example - the problem
only occurs with the prerouting and postrouting hooks.

There is no error when using the input, forward, or output hooks.