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