On 27 April 2016 at 19:14, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
> On Wed, Apr 20, 2016 at 03:43:00PM +0200, Arturo Borrero Gonzalez wrote:
>> Currently, if we choose a set name larger than allowed, the error message is:
>> Error: Could not process rule: Numerical result out of range
>>
>> Let's inform the user with a better error message.
>>
>> We can discuss later if length of set names should be increased, but I think
>> this better error reporting is necessary right now to avoid headaches to users.
>
> /* The max length of strings including NUL: set and type identifiers */
> #define IPSET_MAXNAMELEN 32
>
> I would like that we get the same length as ipset, this should make it
> easier for people to migrate.
>
> This would require a bit of work though since the interface name size
> is limited by the register size. Not much a problem, but it would
> require a bit of code adjustments from the kernel.
>
> So let me postpone this userspace check.
We would need the userspace check anyway to avoid the very misleading
error reporting from the kernel.
Then if tomorrow we change the name length, we just need an oneliner
here to update with the new size. I remember in the past we discussed
using set names as completely variable size strings, but that's
another discussion.
If loading a ruleset with 'nft -f' with lot of nested and included
files, the error is just very difficult to track down; I've hit it
several times already.
== t.nft ==
flush ruleset
table t {
set abcdefghijklmopqrst {
type ipv4_addr
}
}
===========
% nft -f t.nft
t.nft:2:1-2: Error: Could not process rule: Numerical result out of range
table t {
^^
So I don't understand the point in not including some more informative
message right now.
--
Arturo Borrero González
--
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
