[4728] in Kerberos
Re: "ECHO" Problems with V5 telnetd under ultrix 4.3 (FIXED!)
daemon@ATHENA.MIT.EDU (Tad Hunt )
Fri Mar 3 09:34:34 1995
To: kerberos@MIT.EDU
Date: Fri, 3 Mar 1995 05:25:26 GMT
From: tad@csh.rit.edu (Tad Hunt )
Greetings again. I just wanted to let everyone know that I successfully
got telnetd(8), krlogind(8), and login.krb5(1) all happily working together.
I was having problems with echo (telnet) and hanging (rlogin).
I don't know if I solved the problems in the best way possible.
does anyone know where I can submit my diff(1)'s to for inclusion in the
distribution, or someone "official" that I can talk to about the issues
involved with my changes?
It looks like the only thing I have left to solve is setting/propagating
the proper window size... (works fine with telnet(1), but rlogin(1)
doesn't set it...
Thanks,
Tad Hunt
(a) CSH sys admin type :-)
Summary of my changes:
./src/apps/telnet/telnetd/sys_term.c:
DELETED line 1355: ("extern long time();") because time() was
already extern'd
differently...
./src/bsd/login.c:
Beginning around line 378, here are my comments from the code...
/*
* XXX - Tad:
*
* On "ULTRIX mcp.csh.rit.edu 4.3 0 RISC" (uname(1) -a output) boxes,
* Apparently an ioctl(2) call with arguments "(0,TIOCLSET,&ioctlval)"
* where ioctlval is 0 doesn't do what the author intended it to do.
* It unintentionally turns on ICANON input processing, so the
* lgetstr() of the terminal type doesn't complete until a newline is
* fed to login.krb5(1). This is obviously not the intended behavior,
* otherwise the user would have to send a newline (currently ctrl-j)
* before the login process would complete, giving the user his
* shell prompt
*
* My solution: Don't do the ioctl(2). I don't know if this is the
* best solution, but everything seems to work fine without
* it...
*/
/* XXX - Tad:
*
* Kerberos telnetd(8) doesn't pass any of these flags to login.krb5(1)
* on Ultrix boxes with the uname(1) mentioned above -- at least with the
* options that I have compiled in. (default configuration)
*
* I can understand that if a user is going to run login.krb5(1) himself
* they might want to preserve the current tty/pty settings. What I don't
* understand is how the existance of any of these flags on the command
* line implies that the user wants to reset the tty/pty settings.
* Nor do I see a good way to determine (other than a dedicated command
* line argument) if the user doesn't want the tty/pty to be reset.
*
* My Solution: Always call doremoteterm(&tc)
*
* This seems to work fine...
*/
