Date: Tue, 20 May 2014 21:31:28 +0400 From: "Alexander V. Chernikov" <melifaro@FreeBSD.org> To: bycn82 <bycn82@gmail.com> Cc: Dennis Yusupoff <dyr@smartspb.net>, Marcelo Gondim <gondim@bsdinfo.com.br>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Problem with ipfw table add 0.0.0.0/8 Message-ID: <537B9170.6040303@FreeBSD.org> In-Reply-To: <537A0356.7050104@gmail.com> References: <5371084F.1060009@bsdinfo.com.br> <F78BF3AC-F031-4528-A4C1-5B22E88CEC00@dataix.net> <5371112B.2030209@bsdinfo.com.br> <5371E9E7.70400@smartspb.net> <5371F4C8.3080501@FreeBSD.org> <53720AA4.80909@smartspb.net> <537767C5.80205@FreeBSD.org> <53783333.3010205@freebsd.org> <F061517D-0A79-4734-A032-1F2BE060C8F6@dataix.net> <CAC%2BJH2xDM2u97Oa1YsG78x_6xdzTpBS-QD-cSfaWSKkKBU8GDg@mail.gmail.com> <537A0054.5000707@FreeBSD.org> <537A0356.7050104@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@dataix.net>wrote:
>>>
>>>>
>>>>> On May 18, 2014, at 0:12, Julian Elischer <julian@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@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?537B9170.6040303>