Date: Mon, 5 Feb 1996 16:06:01 +0200 (SAT) From: Bertus Pretorius <bertus@mikom.csir.co.za> To: gcrutchr@nightflight.com (Gary Crutcher) Cc: questions@FreeBSD.org, hackers@FreeBSD.org Subject: Re: telnet question Message-ID: <199602051406.QAA15465@zibbi.mikom.csir.co.za> In-Reply-To: <2.2.32.19960205042455.0067d3fc@nightflight.com> from "Gary Crutcher" at Feb 4, 96 08:24:55 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Gary writes
> I have occasionally have a telnet session stop displaying characters. It
> only occurs if I do man <some topic>, 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--------------------+
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602051406.QAA15465>