From owner-freebsd-hackers Sun Apr 13 00:41:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA22393 for hackers-outgoing; Sun, 13 Apr 1997 00:41:38 -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 AAA22386 for ; Sun, 13 Apr 1997 00:41:34 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.7.3) id RAA13731; Sun, 13 Apr 1997 17:48:55 +1000 (EST) Date: Sun, 13 Apr 1997 17:48:54 +1000 (EST) From: "Daniel O'Callaghan" To: Darren Reed cc: adam@veda.is, hackers@freebsd.org Subject: Re: kern/3244: ipfw flush closes connections In-Reply-To: <199704120234.MAA07302@panda.hilink.com.au> 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 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' Danny