Working version: 1.9.2
Broken version: 1.9.3 (5/12/2015) and 1.9.4
Type: regression
Severity: telnetd is unusable for production and hard to use for test
Environment: Arch Linux x86_64 Linux host 4.1.2-2-ARCH #1 SMP PREEMPT
https://www.archlinux.org/packages/core/x86_64/inetutils/
https://wiki.archlinux.org/index.php/Telnet
Problem:
The first connection to the telnetd server usually connects. 90% of additional connections to the telnetd server show the banner then disconnect without a login prompt. Any connection that shows a login prompt works fine.
This happens launched by either xinetd or systemd.
To reproduce:
Make a telnet connection over and over quickly, which is hard to do with command line telnet. A Windowing environment is recommended. Configure a link on the desktop to allow new connections to a telnet server to be launched quickly. Place the link where the window manager doesn't auto place windows, usually near the edges or corners. You can also set the link to launch minimized. Click on the link many times (~10) to bring up many telnet connections in separate windows. 90% of the windows will disconnect and close without a login prompt.
Here's how I do it in PuTTY for Windows:
Create and save a Telnet connection with the following setting:
Close on window exit (*)Always
Create a link on the desktop:
putty.exe -load "Telnet Foo"
Click fast!
Reverting this code change seems to fix the problem.
diff -u4 telnetd.c193 telnetd.c :(
--- telnetd.c193 2015-03-31 11:40:50.000000000 -0400
+++ telnetd.c 2015-07-21 22:35:54.763166900 -0400
@@ -661,9 +661,9 @@
if (FD_ISSET (pty, &ibits))
{
/* Something to read from the pty... */
- if (pty_read () <= 0)
+ if (pty_read () < 0)
break;
/* The first byte is now TIOCPKT data. Peek at it. */
c = pty_get_char (1);
I don't know that this fix is correct but I note some things.
This change drew my attention because a comparison change is non trivial. Other code would need substantial changes for this to be a valid change. Further checking reveals that pty_read and readstream had no substantial code changes that would suddenly include 0 as an error value after being a success value for many years. Without running the code it's hard to find a reason why readstream would return a zero so I can see why a programmer would think this is a safe change. Clearly it does on 90% of login prompts.
The return value of readstream is minimally documented. -1 seems to be an error. 0 is not obvious. 1 appears to be a flag value. 2+ seems to be a length.
I suspect 0 is a valid return value because I think pty_get_char is expected to block when necessary.
This change is documented in the ChangeLog
2015-03-15 Mats Erik Andersson <...>