09 Oct 86 08:38:37 PDT (Thu)
1) Am I correct that the only thing to be sent is IAC, DM? The
description of synch makes it sound like two separate things are sent:
one out of band and the other in the normal data stream. After
reading the description of urgent data about 5 times, I have finally
concluded that this the wrong conception of how urgent data works, and
that in fact only the IAC, DM is sent.
Yes, you only send IAC, DM. You should note, by the way, that BSD systems
have the TCP RFC concept of what the urgent pointer is (one byte PAST the
last byte of urgent data), when the "official protocols RFC" (and the MIL-STD)
have changed the definition to point at the LAST byte of urgent data (a
rather strange definition, given what TCP ack numbers are).
2) I find the whole concept of urgent data slightly odd. Both the
telnet spec and the Unix implementation imply that urgent is some sort
of out of band data, that manages to arrive out of order, going ahead
of any normal data. It looks to me like this isn't quite the case.
Rather there is a bit that says, "go into urgent mode". It seems like
nobody really cares exactly when (i.e. at which byte) you go into
urgent mode. Then there is a pointer that tells you the end of the
urgent data, at which point you go out of urgent mode. 4.2 seems to
have a different view of the world. They pull the last byte of urgent
data out of the normal byte stream and call it out of band data. It's
not clear whether this is quite what TCP had in mind.
Urgent IS out of band data; the only thing is that the out of band data
is only 1 bit worth: "there is an urgent condition present in the
data flow". BSD took the "out of band" approach, and actually tried
to identify an out-of-band BYTE. This is unreliable, and 4.3 allows
a socket option (SO_OOBINLINE) to remove this concept (for incoming
3) The telnet spec further confuses things by saying that DM should be
transmitted as the only octet in an urgent message. The problem is
that this seems to ignore the necessity for an IAC.
The reason for this is, probably, the confusion about which byte is
the urgent byte. What they are saying is "transmit IAC normally,
then transmit DM urgently, then transmit whatever else you want normally"
(ie: two or three seperate calls to "tcp_send").
Anyway, from all of this, I conclude that synch should be implemented
as follows: When I type a ^O, put out an IAC, DM, and set the urgent
pointer so that the DM is the last byte of urgent data (the only byte
as far as Unix is concerned). The way 4.2 works (at least on the
Pyramid), the moment I set the urgent pointer, all packets get the
urgent flag set until the point where the DM has been sent. This
seems to be right.
Because of the confusion about which byte is urgent, because of BSD
being one number too high, because of the TELNET spec's algorithm for
when to LEAVE synch mode, the thing to do is to send the IAC as
urgent (MSG_OOB?), then the DM as normal. Thus, the receiver will
either see the urgent mode go away after receiving the IAC, or
after the DM (the former if the receiver is a BSD system, the latter
if the receiver is some other, MIL-STD conforming, system).
What makes me suspicious of this is the 4.2 telnet seems to get
confused by it. Telnet doesn't set up for the URGENT signal. So the
final urgent byte, the DM, is simply removed from the input stream by
the kernel. The result is mildly odd. When I type ^O, the host ends
up echoing ^O back at me. So the last few bytes of the data stream
are IAC DM <URGENT PTR> ^ O. Since the DM is pulled out by the kernel,
Unix sees IAC ^, which is of course a bogus telnet command, and prints
only the O. If I understand what is going on properly, what I am
sending is right, and it is the combination of 4.2 and 4.2 telnet that
is wrong. Has anybody followed me to this point? Do I seem to be
This is fixed in the 4.3 server (and client).
Fortunately, our two kinds of terminal servers (Bridge CS/100's and
Cisco ASM's) both seem to do the right thing. It's *so* nice to have
^C and ^O work again.
Summary: look in the 4.3 telnet server and client code; implement
SO_OOBINLINE in your kernels.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:58 GMT