* Hints needed to find causes of non-specific error messages
@ 2017-08-23 19:23 Jeff Kletsky
2017-08-23 19:57 ` Jeff Kletsky
0 siblings, 1 reply; 8+ messages in thread
From: Jeff Kletsky @ 2017-08-23 19:23 UTC (permalink / raw)
To: Netfilter Users Mailing list
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Hints needed to find causes of non-specific error messages
2017-08-23 19:23 Hints needed to find causes of non-specific error messages Jeff Kletsky
@ 2017-08-23 19:57 ` Jeff Kletsky
2017-08-23 21:00 ` Jeff Kletsky
0 siblings, 1 reply; 8+ messages in thread
From: Jeff Kletsky @ 2017-08-23 19:57 UTC (permalink / raw)
To: Jeff Kletsky, Netfilter Users Mailing list
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Hints needed to find causes of non-specific error messages
2017-08-23 19:57 ` Jeff Kletsky
@ 2017-08-23 21:00 ` Jeff Kletsky
2017-08-23 21:58 ` Empirically determined limits on identifier name length Jeff Kletsky
2017-08-24 6:35 ` Hints needed to find causes of non-specific error messages Arturo Borrero Gonzalez
0 siblings, 2 replies; 8+ messages in thread
From: Jeff Kletsky @ 2017-08-23 21:00 UTC (permalink / raw)
To: Jeff Kletsky, Netfilter Users Mailing list
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Empirically determined limits on identifier name length
2017-08-23 21:00 ` Jeff Kletsky
@ 2017-08-23 21:58 ` Jeff Kletsky
2017-08-23 23:24 ` Neal P. Murphy
2017-08-24 6:33 ` Arturo Borrero Gonzalez
2017-08-24 6:35 ` Hints needed to find causes of non-specific error messages Arturo Borrero Gonzalez
1 sibling, 2 replies; 8+ messages in thread
From: Jeff Kletsky @ 2017-08-23 21:58 UTC (permalink / raw)
To: Jeff Kletsky, Netfilter Users Mailing list
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
}
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Empirically determined limits on identifier name length
2017-08-23 21:58 ` Empirically determined limits on identifier name length Jeff Kletsky
@ 2017-08-23 23:24 ` Neal P. Murphy
2017-08-24 6:33 ` Arturo Borrero Gonzalez
1 sibling, 0 replies; 8+ messages in thread
From: Neal P. Murphy @ 2017-08-23 23:24 UTC (permalink / raw)
To: Netfilter Users Mailing list
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Empirically determined limits on identifier name length
2017-08-23 21:58 ` Empirically determined limits on identifier name length Jeff Kletsky
2017-08-23 23:24 ` Neal P. Murphy
@ 2017-08-24 6:33 ` Arturo Borrero Gonzalez
2017-08-24 13:49 ` Jeff Kletsky
1 sibling, 1 reply; 8+ messages in thread
From: Arturo Borrero Gonzalez @ 2017-08-24 6:33 UTC (permalink / raw)
To: Jeff Kletsky; +Cc: Jeff Kletsky, Netfilter Users Mailing list
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Hints needed to find causes of non-specific error messages
2017-08-23 21:00 ` Jeff Kletsky
2017-08-23 21:58 ` Empirically determined limits on identifier name length Jeff Kletsky
@ 2017-08-24 6:35 ` Arturo Borrero Gonzalez
1 sibling, 0 replies; 8+ messages in thread
From: Arturo Borrero Gonzalez @ 2017-08-24 6:35 UTC (permalink / raw)
To: Jeff Kletsky; +Cc: Netfilter Users Mailing list
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Empirically determined limits on identifier name length
2017-08-24 6:33 ` Arturo Borrero Gonzalez
@ 2017-08-24 13:49 ` Jeff Kletsky
0 siblings, 0 replies; 8+ messages in thread
From: Jeff Kletsky @ 2017-08-24 13:49 UTC (permalink / raw)
To: Arturo Borrero Gonzalez; +Cc: Jeff Kletsky, Netfilter Users Mailing list
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
>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-08-24 13:49 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-23 19:23 Hints needed to find causes of non-specific error messages Jeff Kletsky
2017-08-23 19:57 ` Jeff Kletsky
2017-08-23 21:00 ` Jeff Kletsky
2017-08-23 21:58 ` Empirically determined limits on identifier name length Jeff Kletsky
2017-08-23 23:24 ` Neal P. Murphy
2017-08-24 6:33 ` Arturo Borrero Gonzalez
2017-08-24 13:49 ` Jeff Kletsky
2017-08-24 6:35 ` Hints needed to find causes of non-specific error messages Arturo Borrero Gonzalez
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.