From owner-freebsd-net@FreeBSD.ORG Sat May 17 15:14:16 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 89AFBB3D; Sat, 17 May 2014 15:14:16 +0000 (UTC) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 43F682C0C; Sat, 17 May 2014 15:14:16 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id j17so4370359oag.15 for ; Sat, 17 May 2014 08:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YZxpt0Tp13VBU7GowUSSDc1V/Yzs3x8oo2tQcdIJFrk=; b=ifczQNYDVhjlx30+CFhRLHAcDcNSB6ozjmTMq7mTMSgzlq+N0YbG/3DCc4zD9IuSfl iiQF4IR1EXe6iyDPVmWqEobqGykQI3eLzXW/O5b7+YqfvU0x6tpaCLu3CMBiVNRjrIN0 Xwz1QnzXOhd7N8/dSSI3B7UvKVZdG1mbpGxdTY3TRkzRBmVxmIDK+hsAaADK/Ppwt4Pv 9bxtx5Wkj3S+jvcP4Aezd1crcfDljCIWGM4sbwWDZ5rM/nk0dxLtjt2IN2mCa7K190rR svTc7YsY2AodQq6RbhwUV48prP++e73D+mUcToK9YtaaokWoq89+3v4D9sI+QjwJo0Vo YMyw== MIME-Version: 1.0 X-Received: by 10.182.213.168 with SMTP id nt8mr23885021obc.7.1400339655561; Sat, 17 May 2014 08:14:15 -0700 (PDT) Received: by 10.76.170.39 with HTTP; Sat, 17 May 2014 08:14:15 -0700 (PDT) In-Reply-To: <537767C5.80205@FreeBSD.org> 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> Date: Sat, 17 May 2014 17:14:15 +0200 Message-ID: Subject: Re: Problem with ipfw table add 0.0.0.0/8 From: Andreas Nilsson To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Dennis Yusupoff , FreeBSD Net , Marcelo Gondim 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: Sat, 17 May 2014 15:14:16 -0000 On Sat, May 17, 2014 at 3:44 PM, Alexander V. Chernikov < melifaro@freebsd.org> 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 ] [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 =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> >>> 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=3Dbin/189471 >>>> >>> I'll try to fix it within a few days. >>> >> Fixed in r266310. > > With all of these changes, would it be possible to get tablearg to store ipv6 as well? I seem to remember it is 32bit only today. Best regards Andreas