From owner-freebsd-hackers Thu Apr 10 16:31:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA08545 for hackers-outgoing; Thu, 10 Apr 1997 16:31:00 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA08530 for ; Thu, 10 Apr 1997 16:30:53 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.7.3) id JAA26462; Fri, 11 Apr 1997 09:36:15 +1000 (EST) Date: Fri, 11 Apr 1997 09:36:14 +1000 (EST) From: "Daniel O'Callaghan" To: Darren Reed cc: Adam David , adrian@obiwan.aceonline.com.au, hackers@freebsd.org Subject: Re: kern/3244: ipfw flush closes connections In-Reply-To: <199704102306.QAA07075@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 11 Apr 1997, Darren Reed wrote: > > I have seen it most often with telnet/rlogin into the "victim" machine, and > > SMTP (and other TCP) connections going weird after 'sh /etc/rc.firewall' > > during normal operation. > > guess: ipfw flush doesn't close any connections but the resulting state of > ipfw after the flush causes all connection info to be lost, resulting in > packets not being forwarded properly and the connection closed,. This is exactly right. I have already committed changes to add the -q flag so that ipfw -q flush does not report the flush. >From the 2.2-RELEASE man page: -q While adding or flushing, be quiet about actions. This is useful for adjusting rules across a remote login session. If a flush is performed in verbose mode, it prints a message. Because all rules are flushed, the message cannot be delivered to the login session, the login session is closed and the remainder of the ruleset is not processed. Access to the console is required to recover. Danny