From owner-freebsd-net@FreeBSD.ORG Mon Jul 7 15:22:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1E696BC for ; Mon, 7 Jul 2014 15:22:55 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [67.212.89.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAB4B2116 for ; Mon, 7 Jul 2014 15:22:55 +0000 (UTC) Received: from mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) by mail.bsdinfo.com.br (Postfix) with ESMTP id 7541A139C8 for ; Mon, 7 Jul 2014 12:22:48 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bsdinfo.com.br; h=content-type:content-type:in-reply-to:references:subject :subject:to:mime-version:user-agent:from:from:date:date :message-id; s=dkim; t=1404746567; x=1405610568; bh=N+GAUioNNa0w 28x1QuMWix6L8q+WPb7jNsEMMs1LNRU=; b=mmxBYrgi23eE1qqdOG2TpJcNU2AP FuBQ4w6vmc0FdMEf2Yez0qoqIAY/rLQE8zxt+hipK+iCKU7lKm3iY4CY99EoS1TI 5rDU2CGgS34N2JcamULHNWk8vQ6V3QnSkPXvwxeoL08MTMHQiLigjPhs51rNFpEQ Ggdqmqou2oik7zE= X-Virus-Scanned: amavisd-new at mail.bsdinfo.com.br Received: from mail.bsdinfo.com.br ([127.0.0.1]) by mail.bsdinfo.com.br (mail.bsdinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhwqARyPvWZk for ; Mon, 7 Jul 2014 12:22:47 -0300 (BRT) Received: from [192.168.88.24] (unknown [186.193.48.8]) by mail.bsdinfo.com.br (Postfix) with ESMTPSA id 4BBDB139C4; Mon, 7 Jul 2014 12:22:46 -0300 (BRT) Message-ID: <53BABB3F.2010603@bsdinfo.com.br> Date: Mon, 07 Jul 2014 12:22:39 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Alexander V. Chernikov" , Dennis Yusupoff , FreeBSD Net Subject: Re: 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> <5377F0BB.1040501@bsdinfo.com.br> <5377F2CB.5010406@bsdinfo.com.br> In-Reply-To: <5377F2CB.5010406@bsdinfo.com.br> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 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, 07 Jul 2014 15:22:56 -0000 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 ] [name >>> "table_name"] >>> * ipfw table name "table_name" >>> * ipfw table "table_name" type >>> >>> 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 >>> 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@mail.xxxxxx.br:/usr/obj/usr/src/sys/GONDIM amd64 > Ah! Sorry! > Is still in the head. > >