Problem with ipfw table add 0.0.0.0/8

[Alexander V. Chernikov]

On 17.05.2014 23:57, Barney Wolff wrote:
> On Sat, May 17, 2014 at 05:44:37PM +0400, Alexander V. Chernikov wrote:
>> 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
> Please avoid violating POLA.  I for one have scripts that automatically add
> entries and would need to be modified if separate ipfw tables become required
> for ipv4 and ipv6.  I'd have no problem, of course, with changes to ipfw
I haven't said anything about splitting IPv4 and IPv6 tables.
> internals as long as the existing public API continues to work.
>