Problem with ipfw table add 0.0.0.0/8

[Marcelo Gondim]

Hi all,

Already exists MFC available to fix this problem in 10-STABLE?

# ipfw table 99 add 0.0.0.0/8
# ipfw table 99 list
::/8 0

Cheers,
Gondim

Em 17/05/2014 20:37, Marcelo Gondim escreveu:
> Em 17/05/14 20:28, Marcelo Gondim escreveu:
>> Em 17/05/14 10:44, Alexander V. Chernikov escreveu:
>>> On 13.05.2014 16:05, Dennis Yusupoff wrote:
>>>> I think that universal table for all kind of data (ipv4, ipv6, ports,
>>>> etc) is a bad idea by design. At least unless you haven't any 
>>>> ability to
>>> It is not always "universal" in kernel.
>>> Actually, different radix tables are used to store both IPv4 and 
>>> IPv6 in single table.
>>>> specify address family on add, to avoid attempts to guess what user
>>>> meant. Something like "ipfw table X add DEEF.DE ipv6".
>>> I'm going to add explicit table type/naming setup soon.
>>> Idea is the following:
>>>
>>> 1) Existing table can be named and addressed by either number or name.
>>> However, you still need to assign table number manually.
>>>
>>> 2) Table type/name can be specified explicitly via one of the 
>>> following commands:
>>> * ipfw table 1 create [type <cidr|u32|ifindex|iface>] [name 
>>> "table_name"]
>>> * ipfw table <num|name> name "table_name"
>>> * ipfw table "table_name" type <cidr|u32|ifindex|iface>
>>>
>>> 3) ipfw(8) stops trying to guess appropriate type based on used 
>>> value. Instead,
>>> it requests table type from kernel and interprets value according to 
>>> returned type.
>>> Default type for all tables is cidr
>>>
>>> 4) Table(s) can be returned to default values using ipfw table 
>>> <num|all|name> destroy.
>>> Destroy means:
>>> * flush
>>> * table tries (or other structures) freed
>>> * type set to cidr
>>>
>>>
>>>>
>>>>
>>>> 13.05.2014 14:32, Alexander V. Chernikov пишет:
>>>>> On 13.05.2014 13:46, Dennis Yusupoff wrote:
>>>>>> May be this will help? See answer on
>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/189471
>>>>> I'll try to fix it within a few days.
>>> Fixed in r266310.
>> The problem still exists.
>>
>> # ipfw table 99 add 0.0.0.0/8
>> # ipfw table 99 list
>> ::/8 0
>>
>> # uname -a
>> FreeBSD mail.xxxxxx.com.br 10.0-STABLE FreeBSD 10.0-STABLE #8 
>> r266370: Sat May 17 19:57:23 BRT 2014 
>> root at mail.xxxxxx.br:/usr/obj/usr/src/sys/GONDIM amd64
> Ah! Sorry!
> Is still in the head.
>
>