Date: Fri, 11 Apr 1997 10:29:13 +1000 (EST) From: "Daniel O'Callaghan" <danny@panda.hilink.com.au> To: Darren Reed <avalon@coombs.anu.edu.au>, Adam David <adam@veda.is>, adrian@obiwan.aceonline.com.au, hackers@FreeBSD.ORG Subject: Re: kern/3244: ipfw flush closes connections Message-ID: <Pine.BSF.3.91.970411102535.10264d-100000@panda.hilink.com.au> In-Reply-To: <Pine.BSF.3.91.970411092935.10264c-100000@panda.hilink.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 Apr 1997, I wrote: > 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. Oops. This text is only in -current's manpage, although the -q option is in 2.2-RELEASE's ipfw. Mike Pritchard, can you please update the RELENG_2_2 man page to reflect reality. Everyone else, please grab ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/sbin/ipfw/ipfw.8 Danny
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.970411102535.10264d-100000>