Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!mailrus!accuvax.nwu.edu!tank!rtp1
From: rtp1@tank.uchicago.edu (raymond thomas pierrehumbert)
Newsgroups: comp.sys.apollo
Subject: Re: kermit
Summary: Kermit ok, telnet settings bad
Keywords: kermit,dn10000
Message-ID: <6586@tank.uchicago.edu>
Date: 6 Dec 89 04:31:48 GMT
References: <6534@tank.uchicago.edu> <6560@tank.uchicago.edu> <6561@tank.uchicago.edu>
Organization: University of Chicago
Lines: 25

In article <6561@tank.uchicago.edu>, rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) writes:
> There is still a curious anomaly regarding my fix of my kermit
> problem.  Namely, when I built kermit on tank (a bsd4.3 ELXSI),
> and accessed it through the SAME incorrectly set terminal server,
> it worked just fine.  Now is that weird or what?

This must look mysterious, but what happened was that my report of
my kermit fix got bounced by the mailer.  The text of the original
message follows:

After reading the .bwr file, and some experimentation, I found that
the problem was that I was dialling in to my Apollo through a
tcp/ip based terminal-access system that assumed 7 data bits,
even parity.  Kermit couldn't put this in "raw mode" since it
is out of its control.  The .bwr file suggests some scary
hacking with telnetd, but fortunately, this system allows you
to reset the parity and data bits even if you use telnet.
I suppose rlogin -8 would also work.  Once I did this,
everything worked fine.

Actually, just setting parity, stopbits and 8bits wasn't enough.
I also had to specify "term download" to this telnet-based
system, which must have something to do with the way carriage
returns and line feeds are handled.
 1