From adam@veda.is  Wed Apr  9 18:34:48 1997
Received: from veda.is (ubiq.veda.is [193.4.230.60])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA03193
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 9 Apr 1997 18:34:46 -0700 (PDT)
Received: (from adam@localhost) by veda.is (8.8.5/8.7.3) id BAA08167; Thu, 10 Apr 1997 01:52:09 GMT
Message-Id: <199704100152.BAA08167@veda.is>
Date: Thu, 10 Apr 1997 01:52:09 GMT
From: Adam David <adam@veda.is>
Reply-To: adam@veda.is
To: FreeBSD-gnats-submit@freebsd.org
Subject: ipfw flush closes connections
X-Send-Pr-Version: 3.2

>Number:         3244
>Category:       kern
>Synopsis:       ipfw flush closes connections
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Apr  9 18:40:01 PDT 1997
>Closed-Date:    Fri Jun 11 03:19:08 PDT 1999
>Last-Modified:  Fri Jun 11 03:25:04 PDT 1999
>Originator:     Adam David
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
Veda Internet
>Environment:

	ipfw used as a filtering firewall component

>Description:

	When ipfw is used to flush previously established rules, (it seems)
        all tcp connections open at the time become closed. Since flush is
	typical at the beginning of ipfw scripts and applies to rules not
	connections, this behaviour is wrong. Several months ago, it was
	possible to circumvent it (at least in part) by running /sbin/ipfw
	as a background process, but no longer.

>How-To-Repeat:

	sh /etc/rc.firewall

>Fix:
	none known
>Release-Note:
>Audit-Trail:

From: Adrian Chadd <adrian@obiwan.aceonline.com.au>
To: Adam David <adam@veda.is>
Cc: FreeBSD-gnats-submit@freebsd.org,
        GNATS Management <gnats@freefall.freebsd.org>,
        freebsd-bugs@freefall.freebsd.org
Subject: Re: kern/3244: ipfw flush closes connections
Date: Thu, 10 Apr 1997 11:45:12 +0800 (WST)

 On Thu, 10 Apr 1997, Adam David wrote:
 
 > 	When ipfw is used to flush previously established rules, (it seems)
 >         all tcp connections open at the time become closed. Since flush is
 > 	typical at the beginning of ipfw scripts and applies to rules not
 > 	connections, this behaviour is wrong. Several months ago, it was
 > 	possible to circumvent it (at least in part) by running /sbin/ipfw
 > 	as a background process, but no longer.
 >
 
 Huh?
  
 > >How-To-Repeat:
 > 
 > 	sh /etc/rc.firewall
 
 Try sh /etc/rc.firewall &
 
 I've noticed the same, if you do it remotely try sh /etc/rc.firewall &
 (I'm running a recentish build of 3.0-CURRENT and open tcp connections
 stay open).
 
 -- 
 Adrian Chadd			| UNIX, MS-DOS and Windows ...
 <adrian@psinet.net.au>		| (also known as the Good, the bad and the
 				|				ugly..)
 
 
 

From: Adam David <adam@veda.is>
To: adrian@obiwan.aceonline.com.au (Adrian Chadd)
Cc: FreeBSD-gnats-submit@freebsd.org, gnats@freefall.freebsd.org,
        freebsd-bugs@freefall.freebsd.org
Subject: Re: kern/3244: ipfw flush closes connections
Date: Thu, 10 Apr 1997 08:41:19 +0000 (GMT)

 > Try sh /etc/rc.firewall &
 
 Sorry, that's exactly what I meant by running it in the background.
 Trouble is that doesn't help anymore.
 
 > I've noticed the same, if you do it remotely try sh /etc/rc.firewall &
 > (I'm running a recentish build of 3.0-CURRENT and open tcp connections
 > stay open).
 
 Weird, I get peer resets all over the place, I've even seen it on throughbound
 connections.
 
 Adam
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: ru 
State-Changed-When: Fri Jun 4 16:04:22 PDT 1999 
State-Changed-Why:  
Does the problem still exist? 
State-Changed-From-To: feedback->closed 
State-Changed-By: ru 
State-Changed-When: Fri Jun 11 03:19:08 PDT 1999 
State-Changed-Why:  
Can't reproduce; originator doesn't respond. 
>Unformatted:
