Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Apr 1997 09:36:14 +1000 (EST)
From:      "Daniel O'Callaghan" <danny@panda.hilink.com.au>
To:        Darren Reed <avalon@coombs.anu.edu.au>
Cc:        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.970411092935.10264c-100000@panda.hilink.com.au>
In-Reply-To: <199704102306.QAA07075@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help


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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.970411092935.10264c-100000>