Linux Netfilter discussions
 help / color / mirror / Atom feed
From: "Neal P. Murphy" <neal.p.murphy@alum.wpi.edu>
To: Netfilter Users Mailing list <netfilter@vger.kernel.org>
Subject: Re: Empirically determined limits on identifier name length
Date: Wed, 23 Aug 2017 19:24:55 -0400	[thread overview]
Message-ID: <20170823192455.4d7ed8f3@playground> (raw)
In-Reply-To: <015d67fd-4453-66df-c4c9-78a17bcbbdd3@wagsky.com>

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


  reply	other threads:[~2017-08-23 23:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170823192455.4d7ed8f3@playground \
    --to=neal.p.murphy@alum.wpi.edu \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox