From owner-freebsd-net@FreeBSD.ORG Mon May 19 08:54:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 332BF780 for ; Mon, 19 May 2014 08:54:26 +0000 (UTC) Received: from quix.smartspb.net (quix.smartspb.net [217.119.16.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF398218F for ; Mon, 19 May 2014 08:54:25 +0000 (UTC) Received: from dyr.smartspb.net ([217.119.16.26] helo=[127.0.0.1]) by quix.smartspb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1WmJOM-000JMP-G5 for freebsd-net@freebsd.org; Mon, 19 May 2014 12:57:54 +0400 Message-ID: <5379C6B6.4030105@smartspb.net> Date: Mon, 19 May 2014 12:54:14 +0400 From: Dennis Yusupoff User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: [Was]: Problem with ipfw table add 0.0.0.0/8 References: <5371084F.1060009@bsdinfo.com.br> <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> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 140518-1, 18.05.2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 08:54:26 -0000 Alex, Bill, it's a good news, glad to hear it. Let me ask even more functionality: 6. Test if entry exist in table: ipfw table test It extremely useful in case of big, unordered data in the table - for example different networks with different mask. Now it's almost impossible to find out is checked IP occurs in the table or not. 7. Are the any reason to keep use numbers only as table names? The more tables uses, the harder to distinct tables in quick look at rules. Compare: ipfw add [line] allow icmp from "table(1)" to "table(2)" and something like ipfw add [line] allow icmp from "table(trusted)" to "table(backbone)" Any comments are welcome. 19.05.2014 11:51, Bill Yuan пишет: > Hi Alex, > > 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. > > 2. Setup the table type > ipfw table type > it will setup the type of the table, and flush the table > > 3. Get table type > ipfw table type show > > 4. Add item into the table > ipfw table add > > a. get the type of table > b. if the type is not defined yet, that also means the table is new or > empty, > then guess the type based on the > c. format the 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. > -- Best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg