From owner-freebsd-questions@FreeBSD.ORG Fri Apr 17 14:56:18 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6926A10656C2 for ; Fri, 17 Apr 2009 14:56:18 +0000 (UTC) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: from mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id 406858FC19 for ; Fri, 17 Apr 2009 14:56:18 +0000 (UTC) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: (qmail 20139 invoked from network); 17 Apr 2009 14:56:17 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Apr 2009 14:56:17 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id A2D2E50825; Fri, 17 Apr 2009 10:56:16 -0400 (EDT) To: KES References: <1873052356.20090416001047@yandex.ru> <44eivsbxfc.fsf@lowell-desk.lan> <598016517.20090416214131@yandex.ru> From: Lowell Gilbert Date: Fri, 17 Apr 2009 10:56:16 -0400 In-Reply-To: <598016517.20090416214131@yandex.ru> (KES's message of "Thu\, 16 Apr 2009 21\:41\:31 +0300") Message-ID: <44myaf72i7.fsf@be-well.ilk.org> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Lowell Gilbert , freebsd-questions@freebsd.org Subject: Re: IPFW missing feature X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-questions@freebsd.org List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 14:56:19 -0000 KES writes: > =D0=97=D0=B4=D1=80=D0=B0=D0=B2=D1=81=D1=82=D0=B2=D1=83=D0=B9=D1=82=D0=B5,= Lowell. > > =D0=92=D1=8B =D0=BF=D0=B8=D1=81=D0=B0=D0=BB=D0=B8 16 =D0=B0=D0=BF=D1=80= =D0=B5=D0=BB=D1=8F 2009 =D0=B3., 15:22:31: > > LG> KES writes: > >>> The tablearg feature provides the ability to use a value, looked u= p in >>> the table, as the argument for a rule action, action parameter or = rule >>> option. This can significantly reduce number of rules in some con= figura- >>> tions. If two tables are used in a rule, the result of the second= (des- >>> tination) is used. The tablearg argument can be used with the fol= lowing >>> actions: nat, pipe, queue, divert, tee, netgraph, ngtee, fwd, skip= to >>> action parameters: tag, untag, rule options: limit, tagged. >>> >>> >>> Why tablearg cannot be used with setfib? > > LG> Because tables are a feature of IPFW, and the FIB isn't. > > setfib is also feature of ipfw. see man: > > setfib fibnum > The packet is tagged so as to use the FIB (routing table) fi= bnum > in any subsequent forwarding decisions. Initially this is li= mited > to the values 0 through 15. See setfib(8). Processing cont= inues > at the next rule. > > There is no any difficulties to use 'tablearg' as 'fibnum' > > ipfw add 3 setfib 2 all from 192.168.0.0/16 to any in recv > ipfw add 3 setfib tablearg all from table() to any in recv > > but now this is not mistake to write 'setfib tablearg'. IPFW just replace= tablearg in rule with 0 > It seems like a bug. because of it MUST work in proper way or DO NOT > work at all. IMHO This does not make sense to me. What do you expect the "tablearg" to be in the second line you listed? That keyword is used to apply the output of an ipfw table lookup, and you haven't used an ipfw table before that line. If you want table() to give back a fib to use, then you need to do that lookup before you do a setfib action. On the other hand, I don't see any point in doing that, because there can only be one result for a given address in your table(), so there's no reason to have more than one FIB. --=20 Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/