Hints needed to find causes of non-specific error messages

Hints needed to find causes of non-specific error messages

[Jeff Kletsky]

Having now split out all my NAT-related statements into an "ip" table 
and shortened all myidentifiers to 16 characters or less, I'm stuck with 
poorly descriptive error messages that only refer to the first line of 
the nft file being read.

The rule set is very skeletal, as I'm still trying to just get the 
chains and sets I need to exist. Most chains are empty, or consist of 
only a "continue" verdict. The vmap-driven dispatch (jump) statements 
have been commented out. "flush ruleset" is the first statement in the 
file read by nft. Commenting out that line just moves the pointer of the 
error message to the next "command" line in the file. nft is being 
executed with root privilege, and I get the same results with nft -c

I had previously found the "Error: Could not process rule: No such file 
or directory" message related to identifiers that are too long.

Previous testing suggested that while set names are called out in the 
wiki as limited to 16 characters, chain names would not cause this kind 
of error at 32 characters or less. There is nothing about the 
identifier-length limit for tables, chains, or variables that I could 
find in the wiki or the current, on-line man page for nft. The nft man 
page describes a valid identifier matches [a-zA-Z][a-zA-Z0-9/\_.]* and 
that quotes are required if it would conflict with an keyword, but 
nothing on length limits.


* What are the limits on identifiers for tables, chains, and variables?


* I'm now looking for suggestions as to what to look at to find the 
source of the following errors:


nftables.conf:3:1-14: Error: Could not process rule: Device or resource busy
flush ruleset
^^^^^^^^^^^^^^
nftables.conf:3:1-14: Error: Could not process rule: No such file or 
directory
flush ruleset
^^^^^^^^^^^^^^
nftables.conf:3:1-14: Error: Could not process rule: Operation not supported
flush ruleset
^^^^^^^^^^^^^^

(As previously noted, "flush ruleset" moves to the next non-comment, 
non-empty line in the file if commented out)


Thanks!

Jeff

Re: Hints needed to find causes of non-specific error messages

[Jeff Kletsky]

I've now tried striping everything out of the chains, except for a lone 
"accept" statement, as well as rebooting.

sudo nft list ruleset # returns nothing

Still getting
nftables.conf:3:1-14: Error: Could not process rule: Device or resource busy
flush ruleset
^^^^^^^^^^^^^^

Have I just been staring at this for too long and am missing something 
obvious?

Jeff


P.S. Please forgive the horrendous names, not much you can do with 16 
characters


$ cat nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table inet global {

     chain prer_r {
         type filter hook prerouting priority -175
         policy drop

         accept

     } # chain prer_r

     chain prer_r {
         type filter hook prerouting priority -50
         policy drop

         accept

     } # chain prer_r

     chain input {
         type filter hook input priority -50
         policy drop

         accept

     } # chain input

     chain forward {
         type filter hook forward priority -50
         policy drop

         accept

     } # chain forward

     chain output {
         type filter hook output priority -50
         policy drop

         accept

     } # chain output

     chain postr_r {
         type filter hook postrouting priority -50
         policy drop

         accept

     } # chain postr_r

     chain postr_n {
         type filter hook postrouting priority 175
         policy drop

         accept

     } # chain postr_n

} # table inet global

table ip nat4 {

     chain nat_prer_4 {
         type nat hook prerouting priority -75

         accept

     }

     chain nat_postr_4 {
         type nat hook postrouting priority 125

         accept
     }

} # table ip nat4



$ lsmod
Module                  Size  Used by
nft_chain_nat_ipv4      1185  0
nf_conntrack_ipv4       6729  1
nf_defrag_ipv4          1236  1 nf_conntrack_ipv4
nf_nat_ipv4             4224  1 nft_chain_nat_ipv4
nf_nat                 12478  1 nf_nat_ipv4
nf_conntrack           70316  3 nf_conntrack_ipv4,nf_nat_ipv4,nf_nat
nf_tables_inet          1265  0
nf_tables_ipv6          1548  1 nf_tables_inet
nf_tables_ipv4          1548  1 nf_tables_inet
nf_tables              55470  4 
nft_chain_nat_ipv4,nf_tables_ipv6,nf_tables_ipv4,nf_tables_inet
nfnetlink               4933  1 nf_tables
ax88179_178a           13649  0
spidev                  6446  0
spi_s3c64xx            11643  0
exynos_gpiomem          3162  0
8021q                  18391  0
garp                    4749  1 8021q
mrp                     6365  1 8021q
stp                     1579  1 garp
llc                     3243  2 garp,stp
ipv6                  340897  26

Re: Hints needed to find causes of non-specific error messages

[Jeff Kletsky]

Found the root cause -- duplicate chain name (prer_r) within the same 
table after all the sed-ing to shorten things.

The error messaging truly needs to be a lot better.


The question of the permitted identifier length is still outstanding.


Jeff



On 8/23/17 12:57 PM, Jeff Kletsky wrote:
> I've now tried striping everything out of the chains, except for a 
> lone "accept" statement, as well as rebooting.
>
> sudo nft list ruleset # returns nothing
>
> Still getting
> nftables.conf:3:1-14: Error: Could not process rule: Device or 
> resource busy
> flush ruleset
> ^^^^^^^^^^^^^^
>
> Have I just been staring at this for too long and am missing something 
> obvious?
>
> Jeff
>
>
> P.S. Please forgive the horrendous names, not much you can do with 16 
> characters
>
>
> $ cat nftables.conf
> #!/usr/sbin/nft -f
>
> flush ruleset
>
> table inet global {
>
>     chain prer_r {
>         type filter hook prerouting priority -175
>         policy drop
>
>         accept
>
>     } # chain prer_r
>
>     chain prer_r {
>         type filter hook prerouting priority -50
>         policy drop
>
>         accept

Empirically determined limits on identifier name length

[Jeff Kletsky]

At least working with the HEAD version of nftables v0.7, current library 
versions, and kernel 4.9,
the limits on identifier length that I have determined empirically (I 
have not examined the code):

* chain, set -- 31 characters
* table -- (not examined, but *guessing* 31 characters as well)

* define -- limit in excess of 65 characters

The error message when the limit is exceeded for the "in-kernel" chain 
and set identifiers is similar to

     nftables.conf:3:1-14: Error: Could not process rule: Numerical 
result out of range
     flush ruleset
     ^^^^^^^^^^^^^^

where the line identified has nothing to do with the offending identifier
(it is the first "actionable" statement of the file)

HTH someone else


Jeff



~/build/nftables$ git log -1
commit d74eed8c9649e9278b69f2cd0fd92f71e3e19cfb (HEAD -> master, tag: 
2017-08-19, origin/master, origin/HEAD)
Author: Varsha Rao <rvarsha016@gmail.com>
Date:   Wed Aug 16 19:48:17 2017 +0530


~/build/libmnl$ git log -1
commit fbe0f33b45abd585eb9f52cb56d751a750667dc6 (HEAD -> master, tag: 
2017-08-19, origin/master, origin/HEAD)
Author: Guillaume Nault <g.nault@alphalink.fr>
Date:   Wed Aug 3 12:52:34 2016 +0200


~/build/libnftnl$ git log -1
commit d58998312375de0865091cfc5d00ddd271d9a44c (HEAD -> master, tag: 
2017-08-19)
Author: Eric Leblond <eric@regit.org>
Date:   Thu Jul 6 13:58:27 2017 +0100

(my libnftl is presently two commits behind origin/master)


kernel 4.9.28-38




$ cat nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table inet global {

     define 
identifier123456789212345678931234567894123456789512345678961234. = one
     define 
identifier123456789212345678931234567894123456789512345678961234_ = one


     chain prerouting12345678921234567893. {
         type filter hook prerouting priority -175
     }

     chain prerouting12345678921234567893_ {
         type filter hook prerouting priority -50
     }

     set identifier12345678921234567893. {
         type inet_service
     }

     set identifier12345678921234567893_ {
         type inet_service
     }

}

Re: Empirically determined limits on identifier name length

[Neal P. Murphy]

With respect to the 'long' identifiers, is it possible that the code reads only so much of the 'token', then reads (treats) the rest of it as the next 'token'? I think I encountered something like this recently in something (but not nftables). If this is the case, it could explain the 'numeric range' error....

Should the code should use a global identifier length so they all have the same length limit (if it doesn't already)?

N


On Wed, 23 Aug 2017 14:58:23 -0700
Jeff Kletsky <jmk@wagsky.com> wrote:

> At least working with the HEAD version of nftables v0.7, current library 
> versions, and kernel 4.9,
> the limits on identifier length that I have determined empirically (I 
> have not examined the code):
> 
> * chain, set -- 31 characters
> * table -- (not examined, but *guessing* 31 characters as well)
> 
> * define -- limit in excess of 65 characters
> 
> The error message when the limit is exceeded for the "in-kernel" chain 
> and set identifiers is similar to
> 
>      nftables.conf:3:1-14: Error: Could not process rule: Numerical 
> result out of range
>      flush ruleset
>      ^^^^^^^^^^^^^^
> 
> where the line identified has nothing to do with the offending identifier
> (it is the first "actionable" statement of the file)
> 
> HTH someone else
> 
> 
> Jeff
> 
> 
> 
> ~/build/nftables$ git log -1
> commit d74eed8c9649e9278b69f2cd0fd92f71e3e19cfb (HEAD -> master, tag: 
> 2017-08-19, origin/master, origin/HEAD)
> Author: Varsha Rao <rvarsha016@gmail.com>
> Date:   Wed Aug 16 19:48:17 2017 +0530
> 
> 
> ~/build/libmnl$ git log -1
> commit fbe0f33b45abd585eb9f52cb56d751a750667dc6 (HEAD -> master, tag: 
> 2017-08-19, origin/master, origin/HEAD)
> Author: Guillaume Nault <g.nault@alphalink.fr>
> Date:   Wed Aug 3 12:52:34 2016 +0200
> 
> 
> ~/build/libnftnl$ git log -1
> commit d58998312375de0865091cfc5d00ddd271d9a44c (HEAD -> master, tag: 
> 2017-08-19)
> Author: Eric Leblond <eric@regit.org>
> Date:   Thu Jul 6 13:58:27 2017 +0100
> 
> (my libnftl is presently two commits behind origin/master)
> 
> 
> kernel 4.9.28-38
> 
> 
> 
> 
> $ cat nftables.conf
> #!/usr/sbin/nft -f
> 
> flush ruleset
> 
> table inet global {
> 
>      define 
> identifier123456789212345678931234567894123456789512345678961234. = one
>      define 
> identifier123456789212345678931234567894123456789512345678961234_ = one
> 
> 
>      chain prerouting12345678921234567893. {
>          type filter hook prerouting priority -175
>      }
> 
>      chain prerouting12345678921234567893_ {
>          type filter hook prerouting priority -50
>      }
> 
>      set identifier12345678921234567893. {
>          type inet_service
>      }
> 
>      set identifier12345678921234567893_ {
>          type inet_service
>      }
> 
> }
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Empirically determined limits on identifier name length

[Arturo Borrero Gonzalez]

On 23 August 2017 at 23:58, Jeff Kletsky <jmk@wagsky.com> wrote:
> At least working with the HEAD version of nftables v0.7, current library
> versions, and kernel 4.9,
> the limits on identifier length that I have determined empirically (I have
> not examined the code):
>
> * chain, set -- 31 characters
> * table -- (not examined, but *guessing* 31 characters as well)
>
> * define -- limit in excess of 65 characters
>

Yes, we have limits in the name of the objects. Probably raising
limits in the future.

> The error message when the limit is exceeded for the "in-kernel" chain and
> set identifiers is similar to
>
>     nftables.conf:3:1-14: Error: Could not process rule: Numerical result
> out of range
>     flush ruleset
>     ^^^^^^^^^^^^^^
>

You complain again and again about this bug (bad error reporting) but
as Pablo told you already, this has been solved.
I know the bug is annoying, but this fixed code isn't included in v0.7.

Reference:
 http://git.netfilter.org/nftables/commit/?id=509671dfa03365bba727b8be5e522b737da93a6f

Re: Empirically determined limits on identifier name length

[Jeff Kletsky]

The referenced patch is, in fact, in the build I am using and have been 
using. The deficit in error reporting is *not* resolved.

As Pablo requested, a fresh build was done and reported here that 
confirmed again that the error-reporting problems were present, even 
with that patch in place.

$ git log --oneline 509671dfa03365bba727b8be5e522b737da93a6f^..2017-08-19

where 2017-08-19 is my local build tag, confirms this.

$ git log -1
commit d74eed8c9649e9278b69f2cd0fd92f71e3e19cfb (HEAD -> master, tag: 
2017-08-19, origin/master, origin/HEAD)
Author: Varsha Rao <rvarsha016@gmail.com>
Date:   Wed Aug 16 19:48:17 2017 +0530


My posts are not about the bug itself, but trying to work through the 
untenable combination of incomplete and/or inaccurate documentation and 
arrive with a Linux-based firewall that I trust to work. Determining how 
a security-sensitive process works by "poking at it with a stick" is 
hardly considered best practice. There are things that you can't poke 
and observe response that either need to be trusted (bad plan), or 
documented as part of the nftables "contract" with its users.

When I first started with nftables and found its documentation to be 
sorely incomplete, I asked on the -devel list how I could best help with 
documentation and there was no response.

<https://wiki.nftables.org/wiki-nftables/index.php/Main_Page>
Third line of the main page:
"If you have any suggestion to improve it, please send your comments to 
Netfilter users mailing list <netfilter@vger.kernel.org>."




On 8/23/17 11:33 PM, Arturo Borrero Gonzalez wrote:
>> The error message when the limit is exceeded for the "in-kernel" chain and
>> set identifiers is similar to
>>
>>      nftables.conf:3:1-14: Error: Could not process rule: Numerical result
>> out of range
>>      flush ruleset
>>      ^^^^^^^^^^^^^^
>>
> You complain again and again about this bug (bad error reporting) but
> as Pablo told you already, this has been solved.
> I know the bug is annoying, but this fixed code isn't included in v0.7.
>
> Reference:
>   http://git.netfilter.org/nftables/commit/?id=509671dfa03365bba727b8be5e522b737da93a6f
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Hints needed to find causes of non-specific error messages

[Arturo Borrero Gonzalez]

On 23 August 2017 at 23:00, Jeff Kletsky <netfilter@allycomm.com> wrote:
> Found the root cause -- duplicate chain name (prer_r) within the same table
> after all the sed-ing to shorten things.
>
> The error messaging truly needs to be a lot better.
>
>
> The question of the permitted identifier length is still outstanding.
>

I replied to your other email thread regarding this very same questions.

Please, don't flood the mailing list with same question in different threads.

thanks.