From owner-freebsd-hackers Mon Feb 5 06:12:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id GAA28273 for hackers-outgoing; Mon, 5 Feb 1996 06:12:58 -0800 (PST) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id GAA27995 Mon, 5 Feb 1996 06:08:03 -0800 (PST) Received: (from bertus@localhost) by zibbi.mikom.csir.co.za (8.6.12/8.6.9) id QAA15465; Mon, 5 Feb 1996 16:06:01 +0200 From: Bertus Pretorius Message-Id: <199602051406.QAA15465@zibbi.mikom.csir.co.za> Subject: Re: telnet question To: gcrutchr@nightflight.com (Gary Crutcher) Date: Mon, 5 Feb 1996 16:06:01 +0200 (SAT) Cc: questions@FreeBSD.org, hackers@FreeBSD.org In-Reply-To: <2.2.32.19960205042455.0067d3fc@nightflight.com> from "Gary Crutcher" at Feb 4, 96 08:24:55 pm X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk Gary writes > I have occasionally have a telnet session stop displaying characters. It > only occurs if I do man , and while viewing the manpages, press > CTRL-C to exit. From that point on telnet works, but no chars display. > > Any ideas of what the problem might be? Yes, we have seen and discuss the problem and agreed to disagree about the problem. Here a description what happens: It is all about out_of_band data (claimed not to exist in TCP/IP) or urgent data. The idea of OOB (I use the for short hand) are suppose to do queue hopping to send a signal to the other side to stop it doing something - most often sending data. The problem is that the current implementations only marks a single OOB character on the recieve side while typically more than one byte is send, which work fine when your data stream is a single TCP connection. However, the moment you go through a proxie you have more than one TCP connection (it happens in al sorts of connection relaying) whith the result that the OOB get stuck, or lost or incomplete because the relay can only get one charackter. Both the transmitting and recieving sides are behaving "wrong" - the quotes indicates that some believe it is right - when handling OOB or urgent data. The specs are however unclear and will most likely remain so:). The full behaviour can easily be detected when you run a simple telnet or ftp relay with tcpdump on both sides. When you pres CNTL-C a chunck, more than one byte (see note), is send while only one is relayed - that is with the trivial implementation. Telnet uses an escape character and a control character and this pair is often split with the result that the one side goes out of sync and wait forever. ftp does it in a more spectacular manner:). note: The TCP packet format contains a field Urgent pointer that points to the fitst octet following urgent data..."and allows the receiver to determine how much urgent data is coming". This can be interpret in two ways: urgent pointer = amount of urgent data or (1) urgent data <= amount of urgent data (2) Case one is the case I make, case to leaves the implementation of OOB or urgent data in TCP at the mercy of the applications:(. Sorry to say a stalemate :( I hope to fix it one day:) -- +-Bertus Pretorius-------- (O) (O) -----------bertus@mikom.csir.co.za-+ | mikomtek ^ +27 12 841-3001 (Voice) | | CSIR \___/ +27 12 841-4720 (FAX) | +-------------A smile is the same in all languages--------------------+