home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!think.com!spool.mu.edu!agate!usenet.ins.cwru.edu!odin!trier
- From: trier@odin.ins.cwru.edu (Stephen C. Trier)
- Newsgroups: comp.protocols.kerberos
- Subject: Re: telnet encryption option vs. Clarkson TCP
- Date: 10 Nov 1992 03:11:51 GMT
- Organization: Case Western Reserve University, Cleveland, OH (USA)
- Lines: 30
- Message-ID: <1dn99nINNca1@usenet.INS.CWRU.Edu>
- References: <CMM.0.90.0.721344901.alan@curta.cc.columbia.edu>
- NNTP-Posting-Host: odin.ins.cwru.edu
-
- In article <CMM.0.90.0.721344901.alan@curta.cc.columbia.edu> alan@CURTA.CC.COLUMBIA.EDU (Alan Crosswell) writes:
- >The problem I have is the telnet session "freezes" right around the
- >TELOPT_ENCRYPTION (option 38) negotiation.
-
- This is *probably* an old bug that I fixed here a few years ago.
-
- The problem is that CUTCP/CUTE thinks there are never more than 34 or 37
- options (I don't remember the exact limit) and if it sees an option above
- the limit, it rounds it down to make it fit. It replies with the rounded-
- down option rather than the correct one, and telnetd ends up waiting for
- an option response that will never arrive.
-
- My solution to the problem was to change the maximum number of options to
- a more reasonable 255. This required changes in only two or three lines
- of code, since the option limit is neatly #defined in a header file.
-
- Warning: I base this on the old "Clarkson NCSA Telnet 2.2D", which was
- released before Clarkson renamed their package to CUTE and stopped releasing
- source. It is therefore quite possible that the bug you are experiencing
- is different.
-
- If you are really desperate, I might be able to dig up my patched Clarkson
- NCSA 2.2D source. Let me warn you that there are a few other local hacks
- in it that you may have to undo in order to make it useful.
-
- --
- Stephen Trier
- Network Services Engineering, IRIS/INS/Telecom
- Case Western Reserve University
- trier@ins.cwru.edu
-