[mod.protocols.tcp-ip] telnet synch

hedrick@TOPAZ.RUTGERS.EDU (Charles Hedrick) (10/06/86)

Almost all of our terminals are now connected to terminal servers
running telnet, instead of directly to computers.  I am getting tired
of typing ^O or ^C and having many screens full of data come out.  The
obvious fix is to implement the Telnet synch option.  I have done so,
more or less, and the improvement is quite welcome.  However the
description in RFC 854 leaves me feeling unsure of whether I have done
things right.  My interpretation of the spec is that when the host
machine wants to clear its output buffer, it should send IAC DM, with
the urgent pointer set to point to the DM.  

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.

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.

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.

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.

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
making sense?

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.

minshall%opal.Berkeley.EDU@UCBVAX.BERKELEY.EDU (10/09/86)

Charles,

    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
data).

    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
    making sense?

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.

Greg Minshall

swb@DEVVAX.TN.CORNELL.EDU (Scott Brim) (10/10/86)

   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.

Does anyone know if Encore Annexes [seem to] do the right thing?
							Scott