[2363] in Kerberos
Re: telnet encryption option vs. Clarkson TCP
daemon@ATHENA.MIT.EDU (Stephen C. Trier)
Mon Nov 9 22:37:46 1992
Date: 10 Nov 1992 03:11:51 GMT
From: trier@odin.ins.cwru.edu (Stephen C. Trier)
To: kerberos@shelby.Stanford.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
