From owner-freebsd-current Mon Apr 22 16:48:05 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA29568 for current-outgoing; Mon, 22 Apr 1996 16:48:05 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA29559 for ; Mon, 22 Apr 1996 16:48:01 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA18180; Mon, 22 Apr 1996 16:44:00 -0700 From: Terry Lambert Message-Id: <199604222344.QAA18180@phaeton.artisoft.com> Subject: Re: socks support native in freebsd? To: pst@shockwave.com (Paul Traina) Date: Mon, 22 Apr 1996 16:44:00 -0700 (MST) Cc: current@FreeBSD.org In-Reply-To: <199604222246.PAA06258@precipice.shockwave.com> from "Paul Traina" at Apr 22, 96 03:46:40 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I know I'm the "let's not bloat things out" guy, but I want to get some > feedback on this idea. It seems like a big gain. > > I'd like to bring socks4 (and later socks5) into the FreeBSD source tree > directly. The reason for doing so is that minor modifications to our > utilities, such as telnet, ftp, et al need to be performed. I figure it > would be more useful to the user community if we just make these changes > /and/ ship our default binaries with socks support included. > > Everything will behave as normal, unless the user creates /etc/socks.conf > which will then enable socks functionality. > > Comments? Socks functionality should be implemented via an IP tunnel; preferrably in a user space "socksd" process. It is a mistake to rebuild "telnet, ftp, et al" to achieve functionality that belongs at the transport layer, not in the applications. This would also fix the OBA (Only Binary Available) problem with trying to use Netscape or Nettrek clinets against a socks server. For what it's worth, this is the same class of thing that should be done to cause the effect that Linux's "IP Masquerading" gets by blatantly violating the RFC's when it isn't really necessary. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.