From owner-freebsd-ipfw@FreeBSD.ORG Tue Apr 3 11:04:37 2007 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 589F316A406; Tue, 3 Apr 2007 11:04:37 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id CB7B613C4AE; Tue, 3 Apr 2007 11:04:36 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l33B4XQq068737; Tue, 3 Apr 2007 08:04:33 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Tue, 3 Apr 2007 08:04:31 -0300 User-Agent: KMail/1.9.5 References: <200704021540.l32FerX8074400@freefall.freebsd.org> <200704021302 .52345.asstec@matik.com.br> <20070403100324.GA1710@rogue.navcom.lan> In-Reply-To: <20070403100324.GA1710@rogue.navcom.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200704030804.31819.asstec@matik.com.br> X-Spam-Status: No, score=-101.0 required=5.0 tests=ALL_TRUSTED, AWL, MR_DIFF_MID, TW_PF,USER_IN_WHITELIST autolearn=unavailable version=3.1.8 X-Spam-Checker-Version: Antispam Datacenter Matik msrv.matik.com.br X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: jonw@whoweb.com, Mike Makonnen Subject: Re: conf/78762: [ipfw] [patch] /etc/rc.d/ipfw should excecute $fire wall_script not read it 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: Tue, 03 Apr 2007 11:04:37 -0000 On Tuesday 03 April 2007 07:03, Mike Makonnen wrote: > I'm not sure I understand. Are you saying the firewall should be enabled > in a precmd() subroutine? If so, I don't think that's a good idea. The > firewall should be enabled only after the firewall script has been > *successfully* loaded. I see your point but first tell me, how do you know that the rules are *successfully* loaded? then, this is about /etc/rc.d/ipfw ok, then ipfw_start checks if=20 firewall-script exist and reads it what was long time wrong, fortunatly fix= ed=20 now, so it executes now then checks if rule 65535 returnes "65535 deny ip from any to any" what als= o=20 is wrong and is ok only on stock kernel/ipfw with default to deny then at the end, regardless of any former checks ipfw_start enables=20 net.inet.ip.fw.enable what obviously is wrong then firstable no check if it is or not to do so, it does not even check if ipfw= is=20 loaded or not, ipfw_precmd might have failed or ipfw is default to accept=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br