From owner-freebsd-net@FreeBSD.ORG Wed Apr 22 17:11:37 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB814106571E for ; Wed, 22 Apr 2009 17:11:37 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forwards5.yandex.ru (forwards5.yandex.ru [77.88.61.37]) by mx1.freebsd.org (Postfix) with ESMTP id 353FB8FC12 for ; Wed, 22 Apr 2009 17:11:37 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from smtp17.yandex.ru (smtp17.yandex.ru [77.88.61.55]) by forwards5.yandex.ru (Yandex) with ESMTP id 23F4AAFBF7 for ; Wed, 22 Apr 2009 21:01:08 +0400 (MSD) Received: from [193.41.172.38] ([193.41.172.38]:61170 "EHLO HOMEUSER" smtp-auth: "kes-kes" TLS-CIPHER: TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S13287675AbZDVRBH (ORCPT ); Wed, 22 Apr 2009 21:01:07 +0400 X-Yandex-TimeMark: 1240419668 X-Yandex-Spam: 1 X-Yandex-Front: smtp17 X-BornDate: 1149541200 X-Yandex-Karma: 0 X-Yandex-KarmaStatus: 0 X-MsgDayCount: 1 X-Comment: RFC 2476 MSA function at smtp17.yandex.ru logged sender identity as: kes-kes X-Nat-Received: from [192.168.9.80]:1167 [ident-empty] by SPAM FILTER: with TPROXY id 1240419773.55807 abuse-to kes-kes@yandex.ru Date: Wed, 22 Apr 2009 20:01:06 +0300 From: Chris Cowart X-Mailer: The Bat! (v4.0.24) Professional Organization: RSSP-IT, UC Berkeley X-Priority: 3 (Normal) Message-ID: <1812419482.20090422200106@yandex.ru> To: freebsd-net@freebsd.org Resent-from: KES MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Resent-Date: Wed, 22 Apr 2009 21:01:07 +0400 Resent-Message-Id: <20090422170108.23F4AAFBF7@forwards5.yandex.ru> Subject: Re: IPFW missing feature X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 17:11:38 -0000 KES wrote: > ????????????, Lowell. > > ?? ?????? 16 ?????? 2009 ?., 15:22:31: > > LG> KES writes: > >>> The tablearg feature provides the ability to use a value, looked up in >>> the table, as the argument for a rule action, action parameter or rule >>> option. This can significantly reduce number of rules in some configura- >>> 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 following >>> actions: nat, pipe, queue, divert, tee, netgraph, ngtee, fwd, skipto >>> 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) fibnum > in any subsequent forwarding decisions. Initially this is limited > to the values 0 through 15. See setfib(8). Processing continues > 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 I use tablearg with netgraph. For example, ipfw add netgraph tablearg all from 'table(9)' to any in When I run ipfw show, I see: 02380 408 60358 netgraph tablearg ip from any to table(9) in KES, do you mean to say that when you run `ipfw show' the rule is echoed back to you as: setfib 0 all from table() to any in recv instead of tablearg? If that's the case, it sounds like ipfw is parsing the rule incorrectly. If tablearg isn't supported by setfib, I would expect a syntax error to be thrown and not a different rule being inserted into your ruleset. If this is the behavior you're seeing, you should run it by the folks on the -net mailing list. That would also be a good place to ask about future plans to support this feature. -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley