SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (11/22/86)
Info-Kermit Digest Fri, 21 Nov 1986 Volume 5 : Number 17
Today's Topics:
WISCVM Arpa/BITNET Mail Relay Congestion
HP9845 Kermit
Okstate Kermit Service Available Once Again
Re: C-Kermit and Xenix 3.0
FIDO and Kermit
Error in CP4KER.DOC
Amiga kermit
C-Kermit 4D(060)
Help needed on Kermit-32 and X25/X29
Kermit and CompuServe
----------------------------------------------------------------------
Date: 14 November 86 18:34 EST
From: Larry Landweber <LHL @ WISCVM.WISC.EDU>
Subject: WISCVM Arpa/BITNET Mail Relay Congestion
Keywords: BITNET, Arpanet
Because of Arpanet congestion problems, our WISCVM mail relay is unable to
keep up with the quantity of mail sent to it for forwarding. While the
problem is particularly acute in the Bitnet to Arpanet direction, the level
of traffic in both directions is a problem. A large part of this traffic
results from mailing lists. Furthermore, while we are usually only sent a
single copy of a list mailing, the recipient list is often very long. A
single message may require the sending of over a hundred copies. This is a
problem for two reasons... Arpanet congesion makes it difficult at times to
establish and keep TCP connections and such connections are slow; second,
the implementation of the gateway at present makes multiple copies for
forwarding (a poor design choice that is being worked on). At present, the
first problem is far [more] significant.
To alleviate the problems cited above and enable us to provide a reasonable
level of service, we are asking Arpanet list maintainers to provide list
exploders on Bitnet and vice versa. Your cooperation will be very much
appreciated. Note that in a about a month we will begin limiting the number
of copies we will relay by putting a limit on the number of recipients in
RCPT TO lines in SMTP and BSMTP. This limit is likely to be 10.
Gligor Tashkovich <RMXJ%CORNELLC.BITNET@WISCVM.WISC.EDU> has agreed to help
coordinate the process of putting maintainers on one net in touch with
relevant people on the other list.
Thanks in advance for your cooperation in this matter.
Larry Landweber
cc: NIC @ SRI-NIC.ARPA CIC @ SH.CS.NET INFO @ BITNIC
PEB @ CERNVM
[Ed. - This is a serious problem. There is not a lot of duplication in the
Info-Kermit list; only a few hosts appear more than twice (they are
VTVM1 (6 times), CALSTATE (5), BROWNVM (3), DACTH51 (3), DBNRHRZ1 (3),
UMKCVAX1 (3), and UREGINA1 (3)). If the subscribers at those hosts could
arrange to combine themselves into a local redistribution list, that would
be appreciated. Meanwhile, we'll try to work out some arrangement so that
mail to BITNET subsribers won't be arbitrarily discarded. But success can't
be promised.]
------------------------------
Date: Fri 21 Nov 86 12:00:35-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: HP9845 Kermit
Keywords: HP9845 Kermit
In Info-Kermit Digest V5 #16 HP9845 Kermit was announced to be in the file
KER:HP9845.*. Accidentally, the files were placed in KER:HP9KER.* This has
been corrected. Sorry for any inconvenience.
------------------------------
Date: Tue, 18 Nov 86 16:05:28 -0600
From: Mark Vasoll <vasoll%a.cs.okstate.edu@RELAY.CS.NET>
Subject: Okstate Kermit Service Available Once Again
Keywords: Okstate
I have reenabled the dial-in modem and about 45 seconds after doing that
someone had logged into uucpker and started grabbing stuff. Looks like
there is still plenty of demand!
Cheers,
Mark
------------------------------
Date: 13 November 1986 0810-PST (Thursday)
From: bierma@nprdc.arpa (Larry Bierma)
Subject: Re: C-Kermit and Xenix 3.0
Keywords: C-Kermit, Xenix
I got kermit running on an AT running IBM's XENIX 1.0 (which is supposedly
the same as Microsoft XENIX 3.0) with no problems. Unfortunatly I don't
remember what "make" option I used and I no longer have the machine.
If no one else gives you better information let me know and I'll get
access to the machine and check what I did.
Larry ARPA: bierma@nprdc.arpa
UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdics!nprdc!bierma
PSTN: (619) 225-2161
[Ed. - Well, there is some feedback. Does anyone have more information?]
------------------------------
Date: Fri, 14 Nov 86 13:52:40 CST
From: plocher@puff.wisc.edu (John Plocher)
Subject: FIDO and Kermit
Keywords: FIDO, Kermit
The Fido kermit problem is deeper than just 8 bit quoting...
I downloaded an ARC file and ran a simple filter on it to
expand 8 bit quoting... BOMB!
The file became much shorter than the original and would not unarc.
Is this because the 8bit decoding can't be done outside of the kermit
state machine? I'm confused as to how to fix this problem:
setting my kermit to use a 7 bit line with 8 bit quoting
does NOT seem to get rid of the problem!
"Never trust an idea you get sitting down" - Nietzche
{harvard,seismo}!uwvax!uwmacc!uwhsms!plocher (work)
John Plocher {harvard,seismo}!uwvax!puff!plocher (school)
decvax!encore!vaxine!spark!121!0!John_Plocher (FidoNet)
------------------------------
Date: Mon, 17 Nov 86 11:35 N
From: <DEGROOT%HWALHW50.BITNET@WISCVM.WISC.EDU>
Subject: Error in CP4KER.DOC
Keywords: CP/M Kermit
Dear Kermit-eers,
There are two tiny little errors in the file CP4KER.DOC.
A small 8080-assembler program is listed which should downline-load the
Kermit-hex-files from a DEC20-system to a CP/M-microcomputer.
line 015A shows: jm 170 This should be: jc 170
line 0167 shows: jm 170 This should be: jc 170
Change the above lines and it really works!
A happy Kermit-eer,
.KeesdeGroot (DEGROOT@HWALHW50)
[Ed. - Thanks for the bug report and the fix. This message has been added
to KER:CP4KER.BWR. This whole program was replaced in the second revision of
the sixth edition of the Kermit User Guide but this file has not yet been
updated.]
------------------------------
Date: Mon, 17 Nov 86 21:55 EST
From: <RICK%QUCDNAST.BITNET@WISCVM.WISC.EDU>
Subject: Amiga kermit
Keywords: Amiga Kermit
Cross-Ref: Commodore Amiga (see also Amiga Kermit)
This may or may not be of interest to anyone there. I obtained what I
believe is the latest version of Amiga Kermit from the Columbia Kermit
server a couple of months back. (I used the earlier one before that.) This
newer version is rather nice, except that it doesn't seem to be able to
generate even parity. The old version worked fine, this newer one does not
seem to generate even parity (at least, not the even parity that the local
IBM 3081 likes) under release 1.1 of AmigaDos. I've tried it with the 1.2
beta serial.device, but no luck. I haven't made any attempt at fixing it; I
am NOT a C programmer (yet?).
Rick Pim
------------------------------
Date: Tue, 18 Nov 86 02:01 EST
From: Kuryan Thomas <THOMASK@VTVAX5.BITNET>
Subject: C-Kermit 4D(060)
Keywords: C-Kermit
[Ed. - The latest version of C-Kermit is 4D(061)]
This is Kuryan Thomas at Virginia Tech Physics department. Some months ago
I reported a problem with C-Kermit running on my AT&T PC6300PLUS under
UNIX System V. I couldn't get the dial command to work -- I would always
get an error like "Can't hang up the phone" or "Communications Disconnect."
After some time as a UNIX administrator and programmer, I've managed to
debug the problem. In function tthang() in ckutio.c, the phone is hung up
by using ioctl() to set the baud rate on the port to 0. This, I believe,
is standard UNIX procedure. On my particular system, though, this operation
always fails with ioctl() signalling an error (-1) and setting errno to
ENXIO (No such device or address). This is definitely a bug, because the
phone IS correctly hung up (DTR line is dropped). The fix is to simply
ignore error returns from the hang-up ioctl() in tthang() (that's the first
ioctl() call in tthang()).
[Ed. - Since this error might be significant on other systems, maybe the
best thing would be to report any error returned by this ioctl(), but then
proceed anyway.]
I uncovered a few other problems, all of which I found (rather kludgy) fixes
for. First, the dial command cannot work unless carrier detect is asserted
on the terminal line. My modem, a Prometheus 1200, refuses to accept the
commands. (Or my tty port refuses to behave correctly, I'm not sure which.)
The fix is to strap CD high with the DIP switches on the bottom panel.
[Ed. - This sounds like another problem with your system. Obviously, CD
will not be asserted until the phone call is completed and carrier is
detected. The system should not require CD to be on while dialing. Strapping
CD high, of course, prevents Kermit or any other program from telling when
carrier really drops.]
Next, my computer, like the 3BX series, expects its lock files in the
directory /usr/spool/locks, rather than /usr/spool/uucp. The problem is
that the former, unlike the latter, is writable only by the uid uucp.
It might appear that the solution is to make ckermit owned by uucp and
set the set-uid bit, but ckermit uses the access() system call to check
write access to the lock directory. access() uses REAL uid's to check
access, not effective uid's. Therefore, set-uid is ineffective. The only
fix I could think of was to remove the lines in look4lk() that report an
error if access() says there's no write permission in the lock directory.
If the set-uid trick is used, all is well and the lock file is created.
If you forget to set the set-uid bit or something else goes wrong, the
attempt to creat() the lock file fails with an error like "Couldn't gain
exclusive access of lock file" or words to that effect.
[Ed. - It seems like every variant of Unix on every different kind of
system puts the "lock files" in different places. And what's more, each
installation sets the permissions differently. Perhaps the next release
of UNIX Kermit will make the lock file location a makefile option, to
emphasize that it has given up all hope of knowing where to find it.]
Finally, the problem of having Kermit hang up the phone when you return to
the shell (thus terminating the conversation) can be solved by strapping
DTR high with the modem's DIP switches. Ckermit can no longer hang up the
phone correctly, but if you often return to your local shell in the middle
of a remote session, the convenience is worth it. And, of course, the
remote end is usually able to hang up the phone correctly when you are done
with it.
[Ed. - Or you can push from Kermit to an inferior shell, leaving the connection
active and all Kermit settings intact -- use the "!" command at prompt level.
A "push" escape will probably also be added to the 'connect' command in the
next release. Setting the modem's "ignore DTR" switch prevents the modem from
noticing when your system crashes, and terminating the connection, resulting in
potentially big phone bills if this happens during unattended Kermit or UUCP
operation.]
Hope this will be of help to someone.
------------------------------
Date: Wed, 19 Nov 86 15:32 GMT
From: Jan Peter Stuart <JPSX@UK.AC.RUTHERFORD.GEC-M> 19-NOV-1986 15:37
Subject: Help needed on Kermit-32 and X25/X29
Keywords: Kermit-32
I was dissappointed to find after my note in newsletter 92, that possibly
no one else uses Kermit-32 on a vax at the end of an X25 line.
So far I have been singularly unsuccessful in getting anything to
function on the outside world!
The problem is now a bit clearer at least. Kermit-32 was designed
to use a vax terminal line. I have no terminal lines to the outside
world, only an x25 connexion that terminates at a DEUNNA board in the
vax. Thus no hardware PAD!
I can certainly establish connections thru the vax X25 without kermit
but does anyone know how to tell kermit-32 to set up an x25/x29 type
of call ????
If I find no other uk users in this position, is there any way I can
request help from the source ? (USA) ?
Yours hopefully,
Jan Stuart.
also direct at uk.ac.rl.gm
------------------------------
Date: Thu, 20 Nov 86 09:18:39 PST
From: Steve Walton <ametek!walton@csvax.caltech.edu>
Subject: Kermit and CompuServe
Keywords: CompuServe
Adding fuel to the fire...
I have had the experience of using Kermit over Telenet. It was not
pleasant. The remote system was the WELL, a 4.2BSD Vax 750 in Berkeley, and
the local system was my Amiga. Version 4D(061) of C-Kermit was used at the
WELL end, and a PD terminal emulator at the Amiga end. Efficiency was 25%.
(Has anyone ever seen C Kermit do better than 65% efficiency?) I finally
gave up on Kermit, and am now using the 1024-byte-packet version of XMODEM
for WELL communication.
Compuserve "B" protocol uses 511-byte packets, which seem to work
fine over Tymnet, Telenet, and the CompuServe net. PeopleLink offers XMODEM
and a new one called "Windowed XMODEM" (!) to get around the delay problems.
When I first arrived on PeopleLink, I suggested windowed Kermit to them as a
new protocol. I haven't asked why they didn't adopt it, but suspect it was
because windowed Kermit is basically nonexistent (except possibly for some
alpha test versions and the IBM PC-only one from the Source). So is
windowed XMODEM, but XMODEM is much closer to universal than Kermit, and is
easily modified to add the window support. After all, we're talking a
strict 8-bit asynch-to-asynch one file at a time protocol.
I love the little green guy, and use it whenever I have a direct
connect line between two machines. But it's a big lose on the
packet-switched nets, and when you're paying by the minute, that's
important.
Stephen Walton ARPA: ametek!walton@csvax.caltech.edu
Ametek Computer Research Div. BITNET: walton@caltech
610 N. Santa Anita Ave. UUCP: ...!ucbvax!sun!megatest!ametek!walton
Arcadia, CA 91006 USA
818-445-6811
[Ed. - Windowed Xmodem is not exactly what you might think -- Since
Xmodem does not have replies (ACKs and NAKs) that are in packet form
so that they can indicate WHICH packet they are ACKing or NAKing,
true sliding windows cannot be supported by any of the MODEM family.
What Windowed Xmodem does is cancel the entire file transfer if any
error is detected. So it's fast when it works, but "infinitely slow"
when it doesn't. C-Kermit will eventually have support for both long
packets and sliding windows.]
------------------------------
End of Info-Kermit Digest
*************************
-------