From owner-freebsd-hackers  Sun Apr 13 02:48:43 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id CAA26399
          for hackers-outgoing; Sun, 13 Apr 1997 02:48:43 -0700 (PDT)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA26392
          for <hackers@freebsd.org>; Sun, 13 Apr 1997 02:48:38 -0700 (PDT)
Message-Id: <199704130948.CAA26392@freefall.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA070594531; Sun, 13 Apr 1997 19:42:11 +1000
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: kern/3244: ipfw flush closes connections
To: danny@panda.hilink.com.au (Daniel O'Callaghan)
Date: Sun, 13 Apr 1997 19:42:11 +1000 (EST)
Cc: avalon@coombs.anu.edu.au, adam@veda.is, hackers@freebsd.org
In-Reply-To: <Pine.BSF.3.91.970413173618.10264z-100000@panda.hilink.com.au> from "Daniel O'Callaghan" at Apr 13, 97 05:48:54 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from Daniel O'Callaghan, sie said:
> 
> 
> 
> On Sat, 12 Apr 1997, Darren Reed wrote:
> 
> > In some mail from Daniel O'Callaghan, sie said:
> > > Have you read my earlier e-mail?  This occurs because if you leave out 
> > > the '-q' option 'flush' says "Flushed all rules".  But when the tcp 
> > > packets come to be sent, and error "Permission denied" is return, so 
> > > telnetd/rlogind quite, kernel resets connection and the rest of 
> > > rc.firewall is probably not executed.
> > 
> > Hmmm, if it returned EHOSTUNREACH, would that be as bad as EPERM ?
> 
> I don't know.  It couldn't be that hard to test, but I'm not really up 
> with predicting kernel behaviour in my head.
> 
> A quick read indicates that ip_input() simply returns if its call to 
> ip_fw_chk() returns -1, which is the case in a deny/reject.  Since rule 
> 65535 is a 'deny' rule, no ICMP is returned, as would be for 'reject'.
> 
> I'm not quite sure where the EPERM comes from - that's just the error you 
> see if you do (at the console) 'ipfw -f flush; ping localhost'

Sorry, I meant EACCESS.

It comes out as a result of a packet being denied.