From: hedrick@dumas.rutgers.edu (Charles Hedrick) Subject: Kermit5A problem solved; scripts start SLIP easily Date: 30 May 1992 20:53:01 GMT
hedrick@dumas.rutgers.edu (Charles Hedrick) writes:
>I've recently started playing with kermit 5A, from binaries/usr.bin on
>tsx-11.mit.edu. I'm interested in getting a script to work.
>Unfortunately I find that it's hard to get this version of kermit to
>work. Now and then it does. But most of the time, when I do a
>"connect", it just comes right back to the kermit> prompt. If I
>reboot the system, the first time, things will work, but then they
>stop working. Any idea what's going on?
Kermit5A seems to be more sensitive to its environment than the
old kermit. In the process of making it work, I had to do:
- create a lock directory, as described in README.5a.
- fix the protection on /dev/tty, since kermit has to be able to
open it
- add a line to .kermrc to make sure "MIN" is set to 1. In
theory this command should look like
run stty min 1 </dev/ttys0
however the stty I've got acts on stdout, and thinks MIN
is a character, so I have to do
run stty min '^A' >/dev/ttys0
where ^A is an actual control-A character, inserted in
Emacs with ^Q. This is a pretty old stty. Presumably the
Gnu one will look like the first example.
The requirement to set MIN seems like it's a bug in both KA9Q and
Kermit. I believe KA9Q should return the tty to the state in which it
found it. However programs do crash and not restore the mode. So if
Kermit is using non-canonical I/O, it should set TIME and MIN to the
values it wants.
With these provisos, Kermit5A works fine for me.
Here are some scripts you may find useful for use with Kermit5A and SLIP:
I assume .kermrc includes at least
run stty min '^A' >/dev/ttys0
set line /dev/ttys0
set speed 9600
with whatever line and speed are appropriate for you. If you use
kermit for several different lines, you'll want to put these commands
somewhere else, or perhaps define a macro that does appropriate
settings for each line.
Here's how I start SLIP. I call this /usr/local/lib/slipdial.cmd. If
you don't put the commands listed above in .kermrc, you could put them
at the beginning of slipdial.cmd. Obviously the specifics are
dependent upon the login and slip commands on our Cisco terminal
servers. The sequence of commands at :dialdone is simply hitting CR a
number of times to get the terminal server to respond. All of my
terminal servers have prompts that end with "top>". The sequence at
:haveprompt is logging in (which is necessary on our terminal servers
before using slip -- this may be a local setup), and then enabling
slip. This code needs some more work. It doesn't check for failure.
It should check for the password being wrong and prompt for another
one. The sequence of commands is as follows: I type "login". It
prompts for "username:" and "password:", both of which I supply. I
then type "slip", and wait for a message that contains the word
"match". (The text is something like "Header compression will match
your system.") Note that I prompt for the password at the beginning.
There's a temptation to hardcode your password into scripts like this.
I strongly recommend against it. Eventually you're going to forget
and give someone a copy of the file, or give someone else your disk
when you upgrade.
askq \%p Password:
set dial display off
set modem hayes
set input timeout proceed
set input echo off
dial 9322857
if success goto dialdone
dial 9322861
if failure goto cantdial
:dialdone
pause 5
output \13
input 2 top>
if success goto haveprompt
output \13
input 2 top>
if success goto haveprompt
output \13
input 2 top>
if success goto haveprompt
output \13
input 2 top>
if success goto haveprompt
output \13
input 2 top>
echo No response to CR
connect
:haveprompt
output login\13
input 3 Username:
output hedrick\13
input 3 Password:
output \%p\13
output slip\13
input 3 match
echo SLIP mode active
exit
:cantdial
echo Dial failed
connect
end
I invoke this script from a shell script called "slip".
#!/bin/sh
kermit /usr/local/lib/slipdial.cmd
Create the preceding file in /usr/bin or /usr/local/bin, and make it
executable.
Once you're turned on slip then you can run KA9Q and do interactive
stuff. I have another script that I often use after setting up slip
but before doing anything interactive. It sets the clock. I suppose
I could do this as part of booting, but somehow I don't like the idea
of having /etc/rc wait to make a dialup connection. The following is
/usr/local/lib/ka9qdate.cmd. It's a modification of my normal
startup.net, so it will need to be modified to be consistent with
yours. It's slightly streamlined, since I don't need to set up any
TCP parameters or domain parameters. It ends up doing an rdate
command to get the date from the other end and set it.
hostname hedrick.rutgers.edu
# ip address [128.6.4.73]
# attach <hw type> <I/O address> <vector> <mode> <label> <bufsize>
# <mtu> [<speed>]
attach asy 0 /dev/tty64 cslip sl0 2048 1500 9600
route add default sl0
bootp silent
ip ttl 16
rdate silent [128.6.4.2]
exit
Here's the shell script I use to invoke it. I call it /usr/local/bin/rdate
#!/bin/sh
net /usr/local/lib/ka9qdate.cmd
clock -u -w
date
The clock command writes the date to the CMOS clock. It assumes your
CMOS clock uses GMT. If it uses local time, omit the -u. The final
date is simply cosmetic: it displays the new date/time.
Of course this script must be run as root, since both the rdate function
in KA9Q and the clock command require root.