Problem with ipfw table add 0.0.0.0/8

[Alexander V. Chernikov]

On 19.05.2014 17:12, bycn82 wrote:
> On 5/19/14 21:00, Alexander V. Chernikov wrote:
>> On 19.05.2014 11:51, Bill Yuan wrote:
>>> Hi Alex,
>> Hello Bill!
>>>
>>> You guys are chatting here! I agree with you, the table is the place 
>>> should
>>> be enhanced, and I am working in this way as described below
>>>
>>> 1. Support more types.
>>> ip   :  cidr
>>> ipv4  : same as ip
>>> ipv6   : ip addr v6
>>> mac   : mac address
>>> iface   : interface name
>>> interface   : same as iface
>>> port    :   it is Alex's idea, I dont know how it works.
>> Well, actually that's not mine. ipfw implement the following since 
>> long ago:
>> +                               v = ((ipfw_insn_u32 *)cmd)->d[1];
>> +                               switch (v) {
>> +                               case 0:
>> +                               case 1:
>> +                                       /* IPv4 src/dst */
>> +                                       break;
>> +                               case 2:
>> +                               case 3:
>> +                                       /* src/dst port */
>> +                                       break;
>> +                               case 4:
>> +                                       /* uid/gid */
>> +                               case 5:
>> +                                       /* jid */
>> +                               case 6:
>> +                                       /* dscp */
>> +                                       break;
>> +                               }
>>
>> I hope you're not using radix to implement mac addresses lookup?
>>
>> Anyway, it looks like we're doing similar things.
>> Can you take a look on '[CFT]: ipfw named tables / different 
>> tabletypes' topic and
>> see how much it conflicts with your changes?
>>>
>>> 2. Setup the table type
>>> ipfw table <id> type <type>
>>> it will setup the type of the table, and flush the table
>>>
>>> 3. Get table type
>>> ipfw table <id> type show
>>>
>>> 4. Add item into the table
>>> ipfw table <id> add <item>
>>>
>>> a. get the type of table <id>
>>> b. if the type is not defined yet, that also means the table is new or
>>> empty,
>>>          then guess the type based on the <item>
>>> c. format the <item> and insert into the table.
>>>
>>> In this way so call "back compatible"
>>>
>>> 5. how to use table
>>>
>>> case 1
>>> ipfw add [line] allow icmp from "table(1)" to "table(2)"
>>> in the ipfw userland command, it should check the table1 and table 2 
>>> should
>>> be ipv4 or ipv6 type
>>>
>>> case 2
>>> ipfw add allow icmp from any to any MAC "table(3)" "table(4)"
>>> in this case, the table(3) and table(4) should be a table of MAC 
>>> addresses.
>>>
>>> case 3
>>> ipfw  add allow icmp from any to any via table(5)
>>> in this case, the table 5 should be table of interface names.
>>>
>>>
>>> currently I am working on the mac type. :)
>>>
>>>
>>>
>>>
>>> On Sun, May 18, 2014 at 12:47 PM, Jason Hellenthal
>>> <jhellenthal at dataix.net>wrote:
>>>
>>>>
>>>>> On May 18, 2014, at 0:12, Julian Elischer <julian at freebsd.org> wrote:
>>>>>> 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"]
>>>>> type "ports" would be nice   but tricky to do right.
>>>> That . . . would be a great addition and have me switching from pf 
>>>> to ipfw.
>>>>
>>>> Pullllease do! :-)
>>> _______________________________________________
>>> freebsd-net at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>>
>>
>>
>
> It is good to know that have company who is  working in the same 
> direction.
> and it is really feeling good to have user who is expecting this 
> feature before implemented. :)
Yup. Named tables (and arbitrary tables) should have been done long time 
ago..
>
> You bring up the code first , I can try to add on a patch for the 
> "mac" type or others , As a newbie here, I am not confident about how 
> to implement is the best way.
Well, stock radix is slow and consumes a lot of memory per record (more 
than 3 cache lines). So it is probably better to implement either array 
of configurable item size or/and hash table.