From owner-freebsd-hackers Thu Dec 16 21:28:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id 28F9314DBC for ; Thu, 16 Dec 1999 21:28:24 -0800 (PST) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id PAA04892; Fri, 17 Dec 1999 15:58:15 +1030 (CST) (envelope-from newton) Date: Fri, 17 Dec 1999 15:58:14 +1030 From: Mark Newton To: John and Jennifer Reynolds Cc: freebsd-hackers@freebsd.org Subject: Re: anybody using tn-gw-nav to tunnel ssh through a proxy? Message-ID: <19991217155814.A448@internode.com.au> References: <14425.10973.878258.39420@whale.home-net> <19991217083227.A3471@internode.com.au> <14425.49856.663134.482116@whale.home-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <14425.49856.663134.482116@whale.home-net> X-PGP-Key: http://www.on.net/~newton/pgpkey.txt Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Dec 16, 1999 at 09:57:36PM -0700, John and Jennifer Reynolds wrote: > > tn-gw isn't 8-bit-clean; you'll need to patch it. Try something like > > this: it creates a new tn-gw-> prompt command called "rawopen" which > > gives you an 8-bit-clean link to whatever host/port you specify. > > When you say 8-bit-clean, what exactly does that mean? Generally speaking it means that certain bytes don't get passed through correctly: You don't end up with a clear 8-bit-wide datapath between point A and point B unless you use special escaping mechanisms. Example: Some systems don't pass through the most-significant- bit of any data presented to them. So if you punch character code 283 (which is binary 100011011) in you'll get character code 27 (which is binary 000011011) out. fwtk isn't quite like that, but it's similar: tn-gw tries to do options spoofing, because it thinks it understands more about things like telnet echo enabling than the server at the other end. So, if you pass character code 255 (which introduces a telnet option) into it from the server side, you get basically nothing popping out at the client side. Meanwhile, you can get telnet options arriving at the client side with no prompting from the server whatsoever if tn-gw happens to think it's a good idea. This doesn't bother telnet one iota (after all, the bogus options are intended to make telnet work better), but it knocks other application layer protocols for six. Solution: Disable the options spoofing which tn-gw tries to do, which is precisely what the patch I posted does. > I'm wondering why this whole charade > works for Linux clients and others (their Makefile also suggests people have > compiled it for Sun, AIX, and the bastard of them all, HP-UX) but not > FreeBSD. What do we do differently? Incidentally, with my patch in place a whole raft of "punch this through the firewall" possiblities arrive. I wrote a proxy which went through a send-expect sequence to "plug-through" any arbitrary TCP port when I was forced to endure a tn-gw proxy with a previous employer; I can provide it (under a BSD-style license) if anyone is interested. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message