leonard@arizona.edu (07/12/90)
We have seen a problem with recent implementations of telnet client talking to VMS/MultiNet. What happens is that, in some cases, output lines echo terminated by <cr> rather than with <cr><lf> - in other words, multiple lines overwrite one on top of the other. We have experienced the problem running telnet from a VAX running the Dec. '89 release of Mt Xinu 4.3BSD into VAXen running MultiNet V2.1 and 2.2. This problem did not manifest in prior releases of the Mt Xinu software, nor does it appear in telnets from the Mt Xinu machine into other systems. Telnet FROM MultiNet into Mt Xinu works fine, as does rlogin from Mt Xinu into MultiNet. Disconcertingly, the most recent software release from Sequent is also seen to manifest the problem (Dynix V3.0.12[?].) (That is, its telnet client behaves the same as Mt Xinu's does.) I infer from this that the problem has crept into the most recent BSD "standard" telnet, and is now appearing in vendors' products. It appears that what happens is this: the MultiNet side issues a <cr><lf><cr> sequence at the end of the line. While this is clearly not optimal (TGV says that this is a problem with the VMS terminal driver), one would think that the second <cr> should be an esthetic noop. The new telnet clients, however, output the line modulo the CRLF, so that such lines echo with only the CR. This seems wrong to me, and is painful to our users. Can anyone verify or rebut my analysis, or offer a workaround?
ddl@husc6.harvard.edu (Dan Lanciani) (07/13/90)
In article <1990Jul11.223443.1@arizona.edu>, leonard@arizona.edu writes: | We have seen a problem with recent implementations of telnet client | talking to VMS/MultiNet. What happens is that, in some cases, output | lines echo terminated by <cr> rather than with <cr><lf> - in other | words, multiple lines overwrite one on top of the other. | | We have experienced the problem running telnet from a VAX running | the Dec. '89 release of Mt Xinu 4.3BSD into VAXen running MultiNet | V2.1 and 2.2. This problem did not manifest in prior releases of | the Mt Xinu software, nor does it appear in telnets from the Mt | Xinu machine into other systems. Telnet FROM MultiNet into Mt | Xinu works fine, as does rlogin from Mt Xinu into MultiNet. | | Disconcertingly, the most recent software release from Sequent is | also seen to manifest the problem (Dynix V3.0.12[?].) | (That is, its telnet client behaves the same as Mt Xinu's does.) | I infer from this that the problem has crept into the most recent | BSD "standard" telnet, and is now appearing in vendors' products. | | It appears that what happens is this: the MultiNet side issues a | <cr><lf><cr> sequence at the end of the line. While this is clearly | not optimal (TGV says that this is a problem with the VMS terminal | driver), one would think that the second <cr> should be an esthetic | noop. The new telnet clients, however, output the line modulo the CRLF, | so that such lines echo with only the CR. This seems wrong to me, and is | painful to our users. | | Can anyone verify or rebut my analysis, or offer a workaround? I believe that you are seeing a bug that was introduced in the "tahoe" release and later "fixed" in the 4.3 networking distribution. (I say "fixed" rather than fixed because the code still doesn't do what it appears to have been intended to do but in fact seems to do nothing at all.) The following is mostly from memory, so check the sources carefully... In the tahoe telnet, look for the "case TS_CR" in the receiver state machine. Observe that the else clause can discard a newline when it shouldn't. Worse, note that the behavior will depend on how much data was available when the last read of the network connection was done! That is, had the newline been in the same buffer as the CR, it would not have been dropped and state TS_CR would not have been entered. Now examine the same case in the 4.3 networking distribution. Note that the else clause has been changed such that if the character is a newline and a few other things are true, the character is added to the output queue. On the other hand, if the character is not a newline or any of the other things are not true, the character is *still* added to the output queue as we fall through to the TS_DATA state. Dan Lanciani ddl@harvard.*