SY.FDC@CU20B.CC.COLUMBIA.EDU (Frank da Cruz) (09/11/85)
Info-Kermit Digest Tue, 10 Sep 1985 Volume 3 : Number 17
Special C-Kermit Edition:
New C-Kermit Bug List
C-Kermit on a 3B2 - Secure Line Locking
Kermit/cu Incompatabilities on the 3B2
C-Kermit Speed on TRS-Xenix
C-Kermit Performance with Parity
C-Kermit Ideas
C-Kermit Remote Server Commands Fail After an Abort
Possible Missing Code in C-Kermit 4C(056)/ckutio 4C(032)
Cancel File Forces Discard of Remaining Files in C-Kermit 4C(057)
Bug in C-Kermit Line Locking
Bug Report For C-Kermit 4C(057)
Problem Installing 4C(057)
C-Kermit Take File Control and Background Operation
C-Kermit on UTS vs the IBM 7171?
Exiting "Protocol Mode" Gracefully
----------------------------------------------------------------------
Date: 10 Sep 85 17:00:00 EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New C-Kermit Bug List
Most of the messages in this issue report bugs and problems with C-Kermit
4C(057), the current (since July 31) release for Unix. The problems are
not urgent, so a new release has not yet been prepared. The problems have,
however, been noted in the "beware" file, KER:CKUKER.BWR, available via
anonymous FTP from Internet host CU20B. Some of the messages below are
over a month old -- apologies; I'm still catching up from the backlog of
mail after a long vacation.
------------------------------
Date: 16 Aug 85 23:01:39 GMT
From: Robert Vidua <gatech!gitpyr!robert@Seismo.ARPA>
Subject: C-Kermit on a 3B2 - Secure Line Locking
I just recently got C-Kermit 4C(055) and brought it up on a 3B2 running
System V Rel 2. I'm trying to use it on a line that uucp also uses and
I'm not sure how to do this without making a potential security problem
and still giving ordinary users full access to the line. I don't want
to modify the code. That leaves me with a two other solutions: 1) make
kermit setuid to something (it doesn't handle this correctly (i.e. no
'setuid (getruid ())' or equivalent), so this isn't a valid solution)
and 2) make the tty line as well as /usr/spool/locks readable and writable
by everyone (nasty if someone decides to get malicious). I'm not too
concerned about the 3B2, since I know/trust all the users on it (it's
a intra-departmental machine), but I'll soon be bringing up the same
kermit on a couple of 3B20s that's open to the whole campus and I'd like
to solve the security problem first.
About two or three months ago, there was a discussion on this very topic
in fa.info-kermit which I, silly me, neglected to pay attention to. Now
I need the information. Does anyone have an archive of those messages
and is willing to send me a copy?
Robert Viduya
Georgia Institute of Technology
UUCP: {akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert
{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
BITNET: CCOPRRV @ GITVM1
[Ed. - The discussions are in the Info-Kermit Digest V2 #11-12, #38-39, and V3
#2. You should be able to pick up the archives over BITNET via KERMSRV at
host CUVMA -- V2 should be called "MAIL 85A" and V3 should be "MAIL TXT".]
------------------------------
Date: 3 Aug 85 16:00:12 EDT
From: Eliot Lear <Lear@RUTGERS.ARPA>
Subject: Kermit/cu Incompatabilities on the 3B2
I am running kermit on an At&T 3B2 running System V.2. I don't know if I am
repeating what someone said but we have discovered that cu requires a line
be owned by uucp while Kermit requires that the line be owned by root.
Since the everyday average user is not allowed to root, this presents
problems. I imagine that this has something to do with checking to see if
the line is active but I don't know. I figured I'd mention it to you,
though.
eliot lear
[Ed. - See previous discussions of line locking.]
------------------------------
Date: Mon, 26 Aug 85 14:46 MDT
From: RMark@DENVER.ARPA
Subject: C-Kermit Speed on TRS-Xenix
After compiling the latest ckermit on TRS-80 Model 16b (v. 7 Xenix), I
timed a transfer from VAX/VMS: 16 chars/sec. I then removed the
-DDEBUG and recompiled. Now over 200 chars/sec at 4800 baud.
[Ed. - As predicted in V2 #35, building the program without the debugging
feature can result in a perceptible speed improvement -- but 1250% is more
than just perceptible! I wonder if the difference is as great on other
systems. In light of this report, it might make sense for every site to
build the program both ways -- use the non-debugging version for production
and the debugging version for tracking down & reporting problems.]
------------------------------
Date: 28-AUG-1985 12:17:47
From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa
Subject: C-Kermit Performance with Parity
Here's a relayed note on C-KERMIT from Tim Green, Computer Unit,
Warwick University UK. If you want to reply send it to me and I'll forward it.
Alan Phillips
Lancaster University
Forwarded message:
I've just put up C-Kermit 4C(057) and have some comments to make regarding
its performance. The performance of C-Kermit on a VAX is fine when you use
it with no parity. Typically I can get 480ch/s on a 9600 baud line.
However due to the local net we have here we can't use it with no parity for
binary files. As soon as you start to use parity the performance is greatly
degraded. This is due to the way C-Kermit tries to detect whether parity is
correct. If you do a profile of it while it is running you find that it is
spending most of its time setting and unsetting a timer. There are two
posible solutions to this. One: Do not test the parity, just assume that it
is correct (leaving error detection to the checksum). Two: provide an
option to set 7bit data when using no parity. We are using a VAX 780 with
4.2 Unix.
[Ed. - You're right about the poor performance when parity is "on". It's
because the program is doing single-character reads rather than reading an
entire "line" (up to a carriage return). It does this because the
terminating CR might have its parity bit on and therefore won't be
recognized as a CR. A more clever scheme will used in a future release to
speed things up. By the way, parity is not used by Kermit for error
checking; rather, Kermit (unlike some other protocols) "tolerates" parity
that is imposed upon it by the communication medium or one of the hosts
involved.]
------------------------------
Date: Sat, 3 Aug 85 00:18:04 pdt
From: "Scott Weikart; Community Data Processing; 415-322-9069"
<cdp!scott@Glacier>
Subject: C-Kermit Ideas
Here's are some comments on items in the recent ckuker.bwr file.
> - When connecting back to C-Kermit after a transaction, or after finishing
> the server, it may be necessary to type a ^Q to clear up an XOFF deadlock.
> There's not much the Kermit program can do about this...
If XON/XOFF is enabled, why couldn't Kermit send an extra ^Q before exitting?
[Ed. - The problem is in the other direction. The local PC needs to send a
^Q to the remote end. But you don't want the PC to do this automatically,
because it might mess things up -- e.g. suppose the remote Kermit was invoked
from within EMACS, which uses ^Q as a command, and has popped to EMACS upon
exit...]
> - ckufio currently goes to a lot of trouble to traverse the directory in
> order to expand "*" and "?" in wildcards. Maybe it should just fork the
> user's customary shell and have it do the expansion. This would allow
> fancier filespecs to be given, like "~/ck*.[cwh]". But it would slow down
> features like filename completion and menus in the interactive command
> parser. (Find out how Unix FTP does it...)
How about forking a shell that's kept around, and communicating
with it through pipes. This way you would only incur the fork and exec
overhead the first time a file name is specified. Various EMACS's use this
technique. In fact, it seems like this could also be used for the
"!" command.
[Ed. - Right, that's the idea. Any volunteers to submit some code for this
that fits in the current framework and works for all versions of Unix?
Would this technique work on small systems, e.g. small-memory PDP-11's?]
------------------------------
Date: Tue, 6 Aug 85 10:46:07 PDT
From: rag@uw-june.arpa (David Ragozin)
Subject: C-Kermit Remote Server Commands Fail After an Abort
Running C-Kermit, 4C(057) under 4.2BSD connected to MS-DOS 2.27 Kermit.
With the C-Kermit side in server mode it responds properly to remote and
remote host commands from the MS-DOS side. However, if I interrupt a remote
command by typing a Control-C on the MS-DOS side, all further remote or
remote host commands fail, except for "remote help". For instance, "remote
dir" elicits the message "Can't list directory", "remote space" gives back
"can't check space", "remote host...." leads to "can't do system command".
Apparantly something on the C-kermit side has been left in a strange state
by the abort.
[Ed. - If you read the MS-DOS Kermit chapter of the Kermit User Guide,
you'll see the explanation. ^C typed to MS-DOS Kermit during a file
transfer returns to MS-DOS Kermit command level "immediately without sending
any kind of notification to the remote system"; it's for use when, for
instance, you give a "send" command but then realize you forgot to start up
a Kermit on the other end. This means that the remote Kermit blithely
continues with what it was doing, in this case sending data packets. If you
waited for a couple minutes (after the other side timed out the maximum
number of times) the situation would have cleared up by itself. If you have
a real transaction in progress that you want to interrupt, then you should
use ^X or ^Z, which most any Kermit server will honor. MS-DOS Kermit also
provides a ^E interrupt, which sends an error packet to the remote side,
which is guaranteed to stop any transaction (assuming it arrives).]
------------------------------
Date: Mon, 12 Aug 85 23:30:16 BST
From: Ljwu@ucl-cs.arpa
Subject: Possible Missing Code in C-Kermit 4C(056)/ckutio 4C(032)
I had a friend of mine in the US snork a copy of C-Kermit and post it to me
on floppy disks. He must have grabbed 4C(056) just before 4C(057) was
released and re-released (see Info-Kermit Digest v3 #10/12). Unfortunately,
the ckctio file seems to lack rtime and gtime routines. I managed to patch
together a working ckctio by including the appropriate lines of code from
ckvtio.c. I hope that this oversight has been remedied in 4C(057).
Script Command, V2.0(006) 14 Jun 85
[Ed. - It has.]
As a footnote, the problem reported earler with wart on a Whitechapel
(Info-Kermit Digest v2 #38) seems to have disappeared.
Les J. Wu - ljwu@ucl-cs.arpa
------------------------------
Date: Tue, 13 Aug 85 17:37:10 PDT
From: rag@uw-june.arpa (David Ragozin)
Subject: Cancel File Forces Discard of Remaining Files in C-Kermit 4C(057)
Setting: C-Kermit 4C(057) BSD version on VAX-11/7xx's under BSD4.2.
Problem: When receiving multiple files a Ctrl-F discards the current file, and
all subsequent files in the same batch. (The transfer of each subsequent
file is started, and then aborted with a discarded message.)
(I seem to remember a report of a problem of this sort a long time ago, but
find no mention in the .bwr file. I have also reproduced the same behavior
between 4C(056) versions.)
[Ed. - Sure enough, it's a bug. Will note this in the .bwr file and fix in
the next release.]
------------------------------
Date: 20-AUG-1985 10:29:51
From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa
Subject: Bug in C-Kermit Line Locking
Forwarded message from Dave Osborne, Cripps Computing Centre, Nottingham U, UK
There is a bug in the the Version 7 unix version of the program. The
ckutio.c module, when opening the line (such as /dev/tty), in its
"ttopen" routine, does an 'ioctl' call with parameter TIOCEXCL, to hold the
line for exclusive use. Unfortunately, it doesn't bother to
unset this condition before closing the line.
[Ed. - This is fixed in the current release.]
------------------------------
Date: 28-AUG-1985 09:58:17
From: SYSKERMIT%vax1.central.lancaster.ac.uk@ucl-cs.arpa
Subject: Bug Report For C-Kermit 4C(057)
I've had a bug report passed to me from Icarus Sparry, Electrical
Engineering Department, Bath University UK.
Bug in C-Kermit 4C(057) and previous releases:
File CKCFN2.C, routine SPACK
If padding is in operation then it is inserted at the start of the packet
before the ^A, as well as at the end of the packet before the EOL. However the
values at the start of the packet are counted for the checksum, (except for the
first) and the ^A is also included in the checksum.
The workaround is to remember where the ^A is or to start the checksum after
npad+1 characters.
[Ed. - Oops! You're absolutely right. This will be noted in the .bwr file,
and will be fixed in the next release. By the way, padding should only be
sent before the packet, not after the end before the terminator -- I have no
idea how that line of code got in there...]
------------------------------
Date: Wed, 4 Sep 85 16:42:51 cdt
From: Dave Rasmussen <uwmacc!uwmcsd1!dave@wisc-rsch.arpa>
Subject: Problem Installing 4C(057)
I have the version that supposedly corrects the 68000 architectural bugs
mentioned by Frank da Cruz on Usenet, the one marked as: C-Kermit, 4C(057)
31 Jul 85, 4.2 BSD
When I tell it to "set line /dev/t1570" where t1570 is owned by uucp and mode
666, kermit just hangs there. The problem is on a 68000 based Integrated
Solutions box running 4.2bsd. I tried running as the superuser in case there
were any file conflicts, but this doesn't change things.
I do have this version running on a Vax 750 with 4.1bsd and it talks to remote
lines with no problems or other modifications.
Any suggestions, or anyone else had these problems? It may well be our
environment, but I think I've looked it over thoroughly.
Dave Rasmussen, CSD University of WI - Milwaukee
[Ed. - Can anyone with a similar system offer any advicde?]
------------------------------
Date: Tue, 3 Sep 85 18:22:15 pdt
From: tweten@AMES-NAS.ARPA (Dave Tweten)
Subject: C-Kermit Take File Control and Background Operation
When I read the contents of the current ckuker.bwr file, with particular
attention to the two items I have previously commented on, I noticed
someone had added editorial comment to each item indicating that this
message is necessary. Though my original message, which included code,
also covered my reasons for the suggestions, I'll repeat the reasons
here.
Some users report that it would be more desirable to have an error
during execution of a take file return directly to command level,
rather than pop to the invoking take file (why?).
Kermit has no flow-of-control commands to be used in TAKE files. It is
therefore impossible to write a TAKE file which does something
intelligent if a file IT TAKEs should die. The result of that fact, and
of the way the unmodified Kermit works, is that multiply nested command
files with an error at the bottom level die a slow and painful death,
wasting the user's time until they work their way back up to the top
level. In background, this is particularly wasteful, since there is
noone to hit ^C to end the nonsense.
My proposal, which I have implemented at our site, is simply a matter of
euthenasia for terminal TAKE files. Where the Columbia-issue command
processor closes the current TAKE file and pops one level, I have put in
a while statement which makes it keep closing and popping until interactive
command level is reached.
[Ed. - Actually, what is needed is a "set" command to control whether this
is done, with which users can "declare" some errors fatal and others not.
The DEC-20 Kermit script facility has something like this.]
Some users report that the program should make no internal
distinction between running in foreground or background (why?).
Release C-Kermit attempts to determine if it is in background by
checking if its parent has set SIGINT to SIG_IGN. That is not a
completely reliable indicator of being in background, and furthermore,
why would it want to know if it is in background?
[Ed. - So it would know whether or not to issue messages to the user's
screen. If in background, attempting to print a message to the screen
freezes the the process.]
The release version changes its behavior in a couple of ways as a
function of whether it thinks it is in background. It sets several
signals to be ignored (which are ignored by default for background
anyway), and it decides to abort immediately on any command failure from
standard input (which prevents graceful termination of a remote server).
Incidently, this is the only way release C-Kermit generates a return
value of BAD_EXIT.
Because C-Kermit's changed behavior in background made it difficult to
debug scripts intended to run in background, I changed ours so it
doesn't try to be different in background.
Ours ALWAYS returns a status value on exit. The status value is always
GOOD_EXIT if no commands have failed, and BAD_EXIT, otherwise. That
makes it easy to debug a shell script which uses a while loop to retry
Kermit a number of times. When a command from standard input fails, our
C-Kermit sets the eventual returned status value to BAD_EXIT and keeps
going, so later commands can gracefully shut down a remote server, if
any.
Over all, I believe our two changes have made C-Kermit much more
civilized, particularly when run from a script. If Columbia would like
diffs for our changes, I would be happy to send a more recent set.
[Ed. - Dave has sent the diffs; does anyone else have any opinions on these
issues? Meanwhile, I'll add a little more in the way of rationale to the
comments in the .bwr file.]
------------------------------
From: ihnp4!inmet!ada-uts!mule@seismo.CSS.GOV
Date: 9 Aug 85 17:08:39 CDT (Fri)
Subject: C-Kermit on UTS vs the IBM 7171?
I am under the impression that the CMS version of Kermit knows how to talk
through the IBM 7171 protocol converter. The 7171 allows ascii devices
(terminals or pc's running terminal emulation programs) to look to the IBM
host like an IBM 3270 type terminal.
We (at Intermetrics Inc 733 Concord Ave Cambridge Mass 02138) are running
UTS on a 3083 IBM host with a 7171 attached. We would love to run a Kermit
that knew about the 7171 and was able to send files back and forth through
it. So:
* Is it true that the CMS kermit knows how to do this ?
[Ed. - Yes.]
* If so, how hard would it be to add this capability to UTS Kermit ?
[Ed. - I believe Philip Murton at the University of Toronto
(MURTON@UTORONTO.BITNET) has done this, or knows someone who did. The
UTS code uses a different technique (escape sequences) than CMS Kermit
(CCW programming).]
* Are there any plans to do so?
[Ed. - Philip, do you have this code for the current, or a recent, release
of C-Kermit?]
* Would you like us to take a shot at it (and where do we go for
help when we need it) ?
[Ed. - Let's see if/how Philip responds. If we don't hear from him, we'll
try to dig up the code he sent us long ago for the old Unix Kermit.]
Thanks,
Fred Mueller (617) 661-1840
PS Thanks in general for devoting so much energy on such a worthwhile
cause. I hope you get lots of kudos for it.
------------------------------
Date: Sat, 7 Sep 85 02:49:35 edt
From: ukma!sean@anl-mcs (Sean Casey)
Subject: Exiting "Protocol Mode" Gracefully
I think that C-kermit should have some provision for completely aborting
the protocol from the terminal. When one is trying to figure out which
parity, flow control, handshaking, etc. settings to use with new computer,
a considerable amount of time may be spent waiting for the local kermit to
give up on the transfer. CTRL/F and CTRL/B are provided to abort a
transfer in progress, but there is no way to abort the protocol without
also exiting kermit (and losing dtr on the line). I'd like to see another
control sequence, perhaps CTRL/X, that would cause the local kermit to
immediately exit the protocol and give the command prompt. Then, when one
is debugging a kermit conversation, the protocol could be easily aborted
as soon as the debugger sees that the two kermits aren't talking
correctly.
- Sean Casey UUCP: sean@ukma.UUCP or
- Department of Mathematics {cbosgd,anlams,hasmed}!ukma!sean
- University of Kentucky ARPA: ukma!sean@ANL-MCS.ARPA
[Ed. - I agree, this has been noted in the .bwr file for some time. MS-DOS
Kermit has a couple options for this which are missing from C-Kermit. They
should be added in future releases.]
------------------------------
End of Info-Kermit Digest
*************************
-------