Date: Thu, 23 Aug 2001 18:23:31 -0700 From: Scott Renfro <scott@renfro.org> To: Barney Wolff <barney@databus.com> Cc: freebsd-net@FreeBSD.ORG, Jonathan Lemon <jlemon@flugsvamp.com>, Jesper Skriver <jesper@skriver.dk>, Bill Fenner <fenner@research.att.com>, Cory Scott <cory@crazypenguin.com> Subject: Re: Proposed change to icmp_may_rst induced ENETRESET Message-ID: <20010823182331.A38019@bonsai.home.renfro.org> In-Reply-To: <20010823165326.A24963@tp.databus.com>; from barney@databus.com on Thu, Aug 23, 2001 at 04:53:26PM -0400 References: <20010822020504.C24160@bonsai.home.renfro.org> <20010823165326.A24963@tp.databus.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 23, 2001 at 04:53:26PM -0400, Barney Wolff wrote: > > As another heavy nmap user, I'd vote just the other way. It's useful > to differentiate between a reset coming back from the destination host > and an unreachable from a firewall/router-acl. Ordinary apps probably > don't care all that much about why a connection could not be > established, and just report the error to the user. I suspect that most (good) applications use strerror(3) to map errors into messages for the user. Today, users get "Network dropped connection on reset"; with the patch they'd get "Connection refused". I think the latter is preferred under POLA, especially when the former is not a documented response to connect(2). You have a valid point that icmp_may_rst changes nmap's behavior, even with the proposed patch. If you want nmap's historic behavior (admin prohib ==> filtered), then turning off icmp_may_rst works. With icmp_may_rst turned on and the patch commited, you get the other behavior (admin prohib ==> closed). Without the patch, nmap spews errors and would need a FreeBSD-specific change. regards, --Scott -- Scott Renfro <scott@renfro.org> +1 650 862 4206 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010823182331.A38019>