On 28 April 2016 at 09:42, Arturo Borrero Gonzalez
<arturo.borrero.glez@xxxxxxxxx> wrote:
> 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.
> --
ping
--
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
