From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 3 11:37:36 2005 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7ECB16A41F for ; Wed, 3 Aug 2005 11:37:36 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9111E43D48 for ; Wed, 3 Aug 2005 11:37:36 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j73BbaEq082624; Wed, 3 Aug 2005 04:37:36 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j73Bba1I082623; Wed, 3 Aug 2005 04:37:36 -0700 (PDT) (envelope-from rizzo) Date: Wed, 3 Aug 2005 04:37:36 -0700 From: Luigi Rizzo To: AT Matik Message-ID: <20050803043736.A82515@xorpc.icir.org> References: <200508021746.j72Hk6Wq006760@lurza.secnetix.de> <200508022151.45925.asstec@matik.com.br> <20050803021151.B80694@xorpc.icir.org> <200508030820.18304.asstec@matik.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200508030820.18304.asstec@matik.com.br>; from asstec@matik.com.br on Wed, Aug 03, 2005 at 08:20:17AM -0300 Cc: freebsd-ipfw@freebsd.org Subject: Re: Another bug in IPFW@ ...? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2005 11:37:37 -0000 the question is simple: i made a mistake in implementing recv|xmit any, Oliver spotted it, i posted a fix. Whether his example was a good one or not is rather irrelevant. Hopefully the discussion has clarified that some checks are redundant, but the compiler cannot possibly spot all useless sequences, and i'd rather not put in useless complexity. The reason "out not in" is printed as "out out" is because "in" is implemented as "not out" and ipfw stores the 'compiled' version in the kernel. cheers luigi On Wed, Aug 03, 2005 at 08:20:17AM -0300, AT Matik wrote: > On Wednesday 03 August 2005 06:11, Luigi Rizzo wrote: > > > there are internally generated packets which do not have > > a rcvif (which is what really 'recv' means); > > and any packet in the input path does not have an output-if > > (which is wht really 'xmit' means). > > > > well, means that any rule using IF here is not catching anything and > you get them as with src-ip and dst-ip only, unless you really can > say "not recv any" or isn't this "not in"? > > nb# ipfw add pass proto ip not in > 65500 allow ip from any to any out > > practically correct? or only logical? > > anyway, looking at the initial rule and what you said a msg before: > > # ipfw add pass ip from $A to $N out not recv any xmit xl0 > 00900 allow ip from $A to $N out xmit xl0 > > "out xmit IF" isn't this kind of unecessary double-check and ipfw > should not accept it? what match first here, ou or xmit? And look > what I get: > > nb# ipfw add pass proto ip src-ip $A dst-ip $N out not in xmit dc0 > 65500 allow ip from any to any src-ip $A dst-ip $N out out xmit dc0 > > > > Hans > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"