info-kermit@ucbvax.ARPA (07/10/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Tue, 9 Jul 1985 Volume 3 : Number 2
KERM and KERK Registered with Apple
Okstate Downtime
Re: MS-Kermit 2.28 Wraparound Backspace
MASM & Kermit
C-Kermit on HP-9000 S500
C-Kermit Line Locking
UUCP Line Locking
Running Pro-3xx P/OS Kermit from Tool Kit
Bug in Prime Kermit
More about 9600 bps Modem
More about PC-Kermit and National Characters
Z100 Comunications Program Query
Kermit on MicroVAX-1?
----------------------------------------------------------------------
Date: Mon 8 Jul 85 18:04:31-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: KERM and KERK Registered with Apple
The Macintosh application names KERM and KERK have been registered with
Apple for Macintosh Kermit and for the Macintosh Kermit Keyboard
Configurator, respectively. These names allow "documents" (e.g. settings
files) created by these programs to be associated with the programs
themselves so that double clicking such a document will invoke the program
with the indicated settings.
------------------------------
To: Info-Kermit@CU20B.ARPA
Subject: Okstate Downtime
Date: 09 Jul 85 06:43:11 CDT (Tue)
From: vasoll%okstate.csnet@csnet-relay.arpa
The system `Okstate' will be down for hardware and software upgrade from
8:00 a.m. July 17th until 5:00 p.m. July 22 (all times central). During
this time the UUCP and Kermit Server line used for the Kermit Distribution
will not be available.
Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University
UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!vasoll
ARPA: vasoll%okstate.csnet@csnet-relay.arpa
------------------------------
Date: Tue, 2 Jul 85 18:20:31 pdt
From: tweten@AMES-NAS.ARPA (Dave Tweten)
Subject: Re: MS-Kermit 2.28 Wraparound Backspace
In Info-Kermit Digest, volume 2, number 40, Greg Small writes:
The backspace from column 1 to column 80 of the previous line
was added for UNIX. For normal input echoing, UNIX assumes
that the terminal handles all margin wraping. This includes
both the normal forward wrap at the right margin and the less
known reverse wrap at column 1. Of course this only impacts
those who enter and then wish to erase characters from lines
longer than 80 characters.
That confuses me. My impression is that bsd UNIX uses curses and termcap
entries to perform terminal independent smart terminal operations. This
includes simulation of wrap-around backspace for terminals whose termcap
entries do not contain the "bw" ("backspace wraps") specifier.
My impression is reinforced by observation of "vi" behavior with long lines.
I used MS-Kermit 2.27 (which correctly emulates H-19 backspace behavior) in
linewrap mode. On multi-row lines, right arrow and space moved me from
column 80 on one row to column 1 on the next. Left arrow and backspace
moved me from column 1 to column 80 of the previous row.
Actually, we have abandoned pretending that a particular
program emulates a real terminal. We now treat each emulator
and version thereof as a seperate terminal type.
This seems to me to be a sad commentary on the current state of design and
implementation of most terminal emulation packages. It is also a little
frightening to consider what this means if you multiply the number of
available terminal emulators (say, for just the vt-100) times the number of
different operating systems which think they know about the terminal being
emulated.
Particularly in the case of Kermit, where Columbia and the user community
have control over the quality of the emulation, it seems to me to make much
more sense to emulate the H-19 well enough that it fools (almost) all the
systems which think they know about it. Users whose systems require a more
faithful emulation than is currently provided should be encouraged to
contribute Kermit code modifications.
Finally, let me reiterate that though I believe strongly in faithful
emulation, and though I can't see how UNIX could require wrap-around
backspace, I don't think wrap-around backspace represents a serious
deviation from the ideal H-19 emulation. I can't imagine that it is common
for programs to send column-1 backspaces to H-19s, realizing that they will
be ignored.
[Ed. - We have received a couple H-19 (Z-19) manuals in response to our plea a
couple issues ago (thanks to those who sent them!), so we should now be able to
emulate this terminal more faithfully...]
------------------------------
From: lotto%lhasa@harvard.ARPA
Date: 28 Jun 85 11:18 EDT
To: harvard!info-ibmpc@usc-isib.ARPA
Subject: MASM & Kermit
If you are building KERMIT with the Microsoft assembler (any version) or the
IBM release (pre 2.0) all will work as written. If however, you are using
MASM 2.0 or later (IBM release) you must specify the /S switch on the command
line for MSXDMB. Be sure the Linker you are using does not predate the
version of DOS by too much. Also, make sure you actually DO have enough
memory to run KERMIT in. A fairly significant chunk of RAM is used by the
new KERMIT, but unlike the previous version, it is allocated by the program.
Gerald Lotto - Harvard Chemistry Dept.
UUCP: {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto
ARPA: lotto@harvard.ARPA
CSNET: lotto%harvard@csnet-relay
------------------------------
Date: Wed, 3 Jul 85 12:16 EDT
From: WIBR@MIT-MULTICS.ARPA
Subject: C-Kermit on HP-9000 S500
I solved that packet-size problem I was having (calling out and trying to
send from my HP9000 Series 500). Apparently, I have to tell the remote host
that I am a vt100, or I get into problems. At least, when I did call myself
a vt100, I was able to send with no problems.
The obvious inconvenience hewith this is that since I really am using an
HP2392A terminal, fun things like EMACS die big if I'm trying to use Kermit
in the same login session. Oh, well.
[Ed. - Could it be that by telling the host you are a VT100, you turn on
its XON/XOFF flow control? Maybe you could tell it you're an HP terminal,
and also tell it to use XON/XOFF, and all will work well.]
A note to HP9000 users out there ( if there are any!): Kermit cannot
use an ASI card interface to a modem if it is to call outside. It needs
to be talking to a MUX board port (properly addressed by read-writeable
ttyxx, cuaxx and culxx files in /dev). Since the ASI board took care of
neat items such as telling the modem to hang up when it's done with it
(using signal lines), and the MUX board cannot, we installed new chips
in our Racal-Vadic's (from them) to interpret a ^C^D sequence flanked by
3 seconds of dead air on either side as a "hangup". Thus, I modified
the Kermit code to echo a "^C^D" to the communications port when exiting
Kermit. Perhaps the best way to do this, would be to modify the
ckudia.c MDMINF struct to include a "hangup_str" parameter. Unless of
course, this is too obscure a scenario...
One further note: ^\^F still doesn't abort a file transfer that is hung up;
neither does ^\^B, for that matter. Does the transfer have to be at least a
little successful ( a few packets here and there) for this to work? If so,
perhaps it is suboptimal?
[Ed. - Right, interrupting a transfer with [^\]{^F,^B} only takes effect
after the first data packet has passed. So there's no good way to interrupt
a Unix Kermit that's stuck trying to start a file transfer, short of ^C'ing
it to stop the program all together. This is noted in the .BWR file.]
------------------------------
Date: Sun, 7 Jul 85 10:14:48 pdt
From: tweten@AMES-NAS.ARPA (Dave Tweten)
Subject: C-Kermit Line Locking
In Info-Kermit Digest, volume 2, number 39, Scott Weikart writes about
Kermit line-locking:
Instead of setuid, I think it would be much better to operate
setgid. Then the ownership of the lock file would be intact. I
put uucp, cu, kermit, etc in a group called dialer, for such
situations.
I agree that the group mechanism is the appropriate tool to use. On our Vax
780, 4.2 BSD system, the system administrator has established a similar
group. The dial-out ttys are owned by the group and are given owner and
group access, and so is /usr/spool/uucp. That way, using /etc/groups, we can
admit users to the group who have a valid need to dial out. We thereby
reduce our exposure to the phone bills which would result from someone
dialing into his favorite Timbuktu bulletin board all day.
To make this system as consistant as possible, we have modified C-Kermit
to make the /usr/spool/uucp "no read access" and "no write access"
warning messages be preventive messages instead. That way, if an access
specification mistake has been made, there is less likelyhood of Kermit
users, tip users, uucp, etc. stomping on one another.
As I see it, the problem can be resolved for all sizes of systems. In a
small system, with a tight group of users, make /usr/spool/uucp and the ttys
publicly accessible. With a larger system, make them group accessible, and
only admit to the group those with a legitimate need to contribute to the
size of the phone bill.
The concern over users' ability to get their work done is resolved by
realizing that on a system which is small and tight-knit enough for public
access to be appropriate, the "system administrator" is likely to be very
accessible (if "he" is not, in fact, just a hat worn by any of several users
when doing system administration tasks). In a larger system, the
administrator has a legitimate need to control access.
I do believe, though, that Kermit's /usr/spool/uucp access warnings should be
made preventive. I believe this for the very reason you (the Info-Kermit
Digest editor) stated in volume 2, number 38:
Assuming that all this can be set up, there still remain ___ major
problems with line locking:
1. Programs will always appear that do not honor the locking
conventions, defeating the entire purpose of the locking
mechanism by simply ignoring it.
With its current access warnings, C-Kermit is just such a program.
------------------------------
Date: Sun, 7 Jul 85 14:53:48 pdt
From: "Scott Weikart; Community Data Processing; 415-322-9069"
<cdp!scott@Glacier>
Subject: UUCP Line Locking
Ken Poulton had talked about wanting to have one kermit process open a
circuit, and then have other kermit processes use that same circuit. His
scheme was to have a kermit exit command that wouldn't close the line. This
scheme has the problem that people will forget to release the tty. I had
suggested an alternative scheme of having subsequent kermits run in a
subshell of the kermit that opened the circuit, so that when you tried to
log off you would pop back into the parent kermit and then exit it and
release the line. I had also suggested that on those systems where
lock-file directories are not accessible by the world, that kermit be run
setgid in a group which has write accesss to the lock-file directory, so
that a) kermit wouldn't have to be setuid and b) the lock file would be
owned by the user account so that subshell kermits could see if their user
owned the tty lock-file. If people wanted kermit to run setuid, I had
suggested writing the account name into the lock-file, so that subshell
kermits would just read the lock-file to see if their user had reserved the
tty.
What follows is a discussion in usenet about a similar problem. The last
note indicates that Honey Danber UUCP uses a similar scheme: it writes
the process ID (PID) into the lock-file. So if kermit used this scheme,
a subshell kermit could read the lock-file and see if its contents match
kermit's PPID (parent PID), as gotten by getppid().
[Ed. - Kermit actually does write the PID into the lock file, but currently
does not use it for anything. Note that not all Unix systems have getppid().]
>>The problem with tip is that, after locking the modem port, it
>>setuid's back to the original invoker's uid/gid. This is
>>supposed to patch the security hole surrounding shell escapes
>>and file transfers. Fine but; alas; it doesn't read /etc/phones...
Another problem this causes involves /usr/spool/uucp security and LCK
files.
It is desirable to have /usr/spool/uucp NOT WRITABLE by the world, as
this leaves a hole for (admittedly clever) vandalism.
However, with the 4.2BSD version of `tip', this causes the LCK files to
be left around after `tip' exits, preventing use of the port until
manual intervention by a "privileged user".
`tip' creates the LCK file while SUID, and no longer has write
permission in /usr/spool/uucp once it changes the UID. The LCK
file therefore remains.
For binary sites the only "solution" seems to be to leave this
directory writable. Yuck.
/+\ Keith F. Pilotti
(UUCP) {decvax,ucbvax}!sdcsvax!telesoft!pilotti
(ARPA) Pilotti@UCSD
a possible solution is to follow honey danber's lock file treatment.
assuming tip's lock files have the same format as uucp's, the lock file
contains the pid of the process that created it.
write a program that reads the lock file and issues signal 0 to the named
pid. if the return is 0 or EPERM, the lock file is valid, otherwise it
should be removed. if binary license is a problem, make tip a shell script
that calls tip, then this program. i leave the details to your imagination.
peter
[Ed. - Let's keep this discussion going until some kind of concensus is
reached. My concern is that whatever mechanism is settled upon is rational,
humane, simple, installable, maintainable, and explainable.]
------------------------------
Date: 7 Jul 85 19:01:41 EDT
From: D. M. Rosenblum <DR01@CMU-CC-TE>
Subject: Running Pro-3xx P/OS Kermit from Tool Kit
Users of PRO/Kermit may be interested to know that PRO/Kermit can be run from
PRO/Tool Kit, instead of from the main P/OS menu. This is useful if you are
in the habit of going directly into PRO/Tool Kit and doing everything from
there. Here's how to do this.
Suppose you have installed PRO/Kermit in a menu on a hard disk system.
KERMIT.TSK will be in a directory of the form [ZZAPnnnnn], where nnnnn is a
system-dependent five-digit number (you will have to do some hunting to find
which such directory KERMIT.TSK is in). PRO/Tool Kit's START.CMD and
EXIT.CMD files will also be in a directory of the form [ZZAPmmmmm] (where
mmmmm is not equal to nnnnn). You should APPEND the following lines to
[ZZAPmmmmm]START.CMD, replacing [ZZAPnnnnn] throughout by the name of the
directory in which KERMIT.TSK resides.
;
; Install PRO/Kermit Version 1.0
;
; Note that the reference to [ZZAPnnnnn] in the line that installs
; KERMIT must be changed if PRO/Kermit is removed from the menus and re-
; installed there.
;
.DISABLE QUIET
.IFNINS KERCON INSTALL [ZZKERMIT]KERCMN
.IFNINS KERCON INSTALL [ZZKERMIT]KERCON/NOREMOVE
.IFNINS KERFIL INSTALL [ZZKERMIT]KERFIL/NOREMOVE
.IFNINS KERMIT INSTALL [ZZAPnnnnn]KERMIT
.ENABLE QUIET
(the PRO DCL indirect command processor has no way of testing to see whether a
common region has been installed, so you have to instead check to see whether
some task, that you're careful to have installed if and only if that common
region is installed, has been installed in order to determine whether the
common region has been installed -- this makes the order of the commands in the
START.CMD file important).
You should also append the following lines to [ZZAPmmmmm]EXIT.CMD.
;
; Remove PRO/Kermit Version 1.0
;
; Note that we do not remove KERCON, KERFIL, or KERCMN (which is a
; common region), since the first two are normally installed with the
; /NOREMOVE option (when Kermit is run from the menu in P/OS), and the
; third is not normally removed when Kermit is exited.
;
.DISABLE QUIET
.IFINS KERMIT REMOVE KERMIT
.ENABLE QUIET
If you are on a diskette system, all references to directories [ZZAPmmmmm] and
[ZZAPnnnnn] should be replaced by [ZZAPPL]. Otherwise, as far as I can tell,
the procedure is the same (I don't have access to any diskette-based PROs, so
I can't tell if this really works -- in other words, it's untested).
Once you have made these additions to the .CMD files, all that you have to do
in Tool Kit to run PRO/Kermit is issue a RUN KERMIT command. You will then be
in Kermit's top-level menu, and you may proceed as usual. When you exit
PRO/Kermit, you will be back in Tool Kit.
------------------------------
Date: Wed 3 Jul 85 00:13:21-PDT
From: Bob Larson <BLARSON%ECLD%ECLA@columbia.arpa>
Subject: Bug in Prime Kermit
Testing the new os9 kermit, I found another bug in Prime kermit. When in
server mode, Prime kermit will Ack an 'R' packet, then send a Send-Init
packet. According to the protocol manual, it is not suposed to send the
'Y' (Ack) packet. I had to modify the os9 kermit to ignore the extra Ack.
[Ed. - If Prime Kermit really does this, it's a bug. I've forwarded Bob's
message to the Prime Kermit authors.]
------------------------------
Date: Wed, 3 Jul 85 21:24 EDT
From: Frankston@MIT-MULTICS.ARPA
Subject: More about 9600 bps Modem
Since a few people are asking me about the modem I mentioned, I will pass on
the information. This is for informational purposes only and is not a
comment pro or con:
It is the UPTA96 modem from Electronic Vaults, Inc. Their phone number is
703-883-0332. It presents a full duplex interfaces but transmits half duplex
using its own error correcting protocol. It can drop back to 7200 or 4800
under program control. It uses either XON/XOFF or CTS/DTR flow control.
It is available as a standalone modem or as a board for the IBM PC. It uses
a standard RJ11 jack.
------------------------------
Date: Fri, 5 Jul 85 15:46:22 -0200
From: Frithjov Iversen <iversen%vax.runit.unit.uninett@NTA-VAX>
Subject: More about PC-Kermit and National Characters
What I had in mind, is what you refer to as SET CHARACTER. Anyway, the
feature need not include the ability to switch between different font sets in
ROM. It could be implemented as a simple 256-byte lookup-table. When ASCII
<xxx> comes in,look it up, and it turns into <yyy> before sending it to the
screen. One may assume that the National character ROM already is in effect.
-fi
------------------------------
Date: Tuesday, 2 July 1985 11:43-MDT
From: Dave Shanks <shanks%teneron.uucp@BRL.ARPA>
Subject: Z100 Comunications Program Query
Does anyone out there know of a good communications program for the
Heath/Zenith H/Z100 under MS-DOS which supports both the serial ports?
I am specifically looking for a program which will allow me to switch
ports on the fly. It would be nice if the program were in the public
domain, but not necessary. Thanks in advance.
Dave Shanks ..!tektronix!reed!teneron!shanks
Teneron Corp.
6700 SW 105th Suite 200
Beaverton, OR 97005
(503) 646-1599
[Ed. - Does anyone have experience using MS-DOS Kermit on the Z100 with
two ports?]
------------------------------
Date: Mon, 8 Jul 85 11:56:14 EDT
From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
Subject: Kermit on MicroVAX-1
Is there any experience with Kermit on the MicroVAX-1?
[Ed. - Comments appreciated, of course, about either VMS or Unix on the
MV-I, or the MV-II for that matter.]
------------------------------
End of Info-Kermit Digest
*************************
-------