Hello Claude, Sorry for letting you wait this long. I was in a rush this afternoon, so I couldn't fix it for you right away. It turns out there was a small inconsistency between the old and the new pseudo-terminal driver, which caused telnetd to exit prematurely. The new pts(4) driver did not track any state on if it had been used already. This meant that when select() in telnetd would be called right before the child processes had opened the TTY device node, it would just assume that the session was already finished. I've committed a fix to SVN (183308), which should removes this inconsistency. I assumed it wouldn't be a very important problem, because most of the PTY consumers already use the openpty() routine, which already opens the TTY device node unconditionally. It turns out some things went bad after all. Could you try updating to the latest sources to see if the problem is solved now? I've also spotted another `bug' in telnetd. If I log in to telnetd, I see the following message appear in dmesg: pid 2362 (telnetd) is using legacy pty devices This means telnetd has its own PTY allocation routines, instead of using posix_openpt(2) or openpty(3). I've attached a patch that converts telnetd to openpty(3). I'll see if I can get this patch or something similar integrated. Thanks for reporting the issue! -- Ed Schouten <ed_at_80386.nl> WWW: http://80386.nl/
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:35 UTC