Date: Sun, 13 Apr 1997 19:42:11 +1000 (EST) From: Darren Reed <avalon@coombs.anu.edu.au> To: danny@panda.hilink.com.au (Daniel O'Callaghan) Cc: avalon@coombs.anu.edu.au, adam@veda.is, hackers@freebsd.org Subject: Re: kern/3244: ipfw flush closes connections Message-ID: <199704130948.CAA26392@freefall.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
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704130948.CAA26392>