PVJQC@CUNYVM.BITNET (02/01/91)
HI PEOPLE, THIS IS A POSTING ON BEHALF OF MARK TARDIVEAU. HE HAS RESPONDED TO MY EARLIER POSTING REGARDING NCSA TELNET (2.2D) WITH NEXT RELEASE 2.0. --Prashant ------ HIS MESSAGE FOLLOWS... The new telnetd in NextStep 2.0 comes from 4.3-Reno, and seems to be, shall we say, too sophisticated for old programs like NCSA Telnet (and just about every other telnet in the known universe). To fix the problem, you have to replace the new telnetd with the old one from 1.0. This was pointed out to me by Scott Hess (Thanks, Scott !). --------------------------------------------------------------- Max Tardiveau Department of Computer Science University of St.Thomas St.Paul, MN 55105 Internet : m9tardiv@cs.stthomas.edu --------------------------------------------------------------- "All I ask is a chance to prove that money can't make me happy." : root nextserv 1/31/91 :Max Tardiveau PVJQC@cunyvm.cuny.e 1/31/91 NextStep 2.0 and NCSA Telnet
louie@sayshell.umd.edu (Louis A. Mamakos) (02/01/91)
>The new telnetd in NextStep 2.0 comes from 4.3-Reno, and seems to be, >shall we say, too sophisticated for old programs like NCSA Telnet >(and just about every other telnet in the known universe). To fix the >problem, you have to replace the new telnetd with the old one from >1.0. It seems to me that the way to "fix" this problem is to fix the problem, and not the symptom. Your problem is NCSA telnet, and not the telnet daemon on the NeXT. Replacing the telnetd on the NeXT makes it possibe to operate with your NeXT, but you're still going to be stuck if you try to connect to any other machine that provokes the NCSA telnet bug. louie
heal@mrcnext.uiuc.edu (Loren E. Heal) (02/02/91)
The problem is, of course, that the old telnetd had a well-known Berkeley-derived BUG. NCSA's code up through 2.2 depended on that bug; I understand that the problem is fixed in NCSA Telnet 2.3. I'm not sure about the fixedness, though. Clarkson University Telnet v2.2 works with the NeXT 2.0 telnetd. It's available from omnigate.clarkson.edu (128.153.4.2) via anon-ftp. NCSA Telnet 2.3beta is available at ftp.ncsa.uiuc.edu. -- *----------------------------------------------------------------------* : Loren E. Heal : leheal@uiuc.edu (from *net, you figure it out) : :(Not a spokesman for the University of Illinois at Urbana-Champaign) : :(I may work there, but I still own my own mind!) : *----------------------------------------------------------------------*
eps@toaster.SFSU.EDU (Eric P. Scott) (02/04/91)
In article <91031.224509PVJQC@CUNYVM.BITNET> PVJQC@CUNYVM.BITNET writes: >The new telnetd in NextStep 2.0 comes from 4.3-Reno, and seems to be, >shall we say, too sophisticated for old programs like NCSA Telnet >(and just about every other telnet in the known universe). WRONG. The problem is unique to the IBM PC (you actually have an early Clarkson release, not an NCSA release). It's a bug which is not present in the current Clarkson or NCSA releases--or any other implementation or PC telnet I've tried, nor does it affect NCSA Telnet for the Macintosh or its derivatives. > To fix the >problem, you have to replace the new telnetd with the old one from >1.0. That one is broken, broken, broken. That's why we flushed it as soon as we could. I'm aware of *five* public releases of BSD telnetd newer than what was shipped with 1.0: [NeXT 1.0] 5/12/86 4.3-tahoe(?) 2/23/89 telnet.90.03.01 3/ 1/90 telnet.90.06.28 6/28/90 <- your telnet broke here 4.3-reno 6/30/90 telnet.90.09.14 9/14/90 BTW, I *don't* recommend the 90.09.14 telnetd, just its telnet. -=EPS=-