gnu@hoptoad.UUCP (11/20/87)
{I wrote these as an addendum to Mark Weiser's instructions for installing
slip into a binary Sun kernel, since he forgot to mention anything but
the kernel modification. Mark's SLIP is available on mimsy.umd.edu.}
The SIOCIFDETACH definition above should use a number that is not already
in use; more recent Sun releases have already used ioctl (i, 23), so
just pick a number beyond the last one they used. Also, make sure that
both /usr/include/sys/ioctl.h and /usr/sys/h/ioctl.h are updated.
They may be links or symbolic links, or may be separate files.
The code I use has a fix from Chris Torek folded in, which improves the
handling of when to start and stop the serial port. It also has the
"sldetach" routine added to the end of the source, though I believe
it is not called from the right place(s), or is not right, since
you still end up burning an interface every time you lose a SLIP
connection.
The above description assumes you know how to configure a Sun or BSD
kernel. If you don't, look in the system installation manual, it gives
detailed instructions on this. You will have to make the changes
specified above by Mark, (except the "pseudo-device" line), then do the
kernel configuration process as documented in the manual, inserting the
"pseudo-device" line into your custom config file. Run "/etc/config"
then "make" then move the new kernel into the root directory, as e.g.
"/vmunix.new". You will also have to allocate a bunch more "character
lists (clists)" which are buffers for the serial ports -- you are
driving these ports heavier than usual. Easiest way to do this is by
patching your new kernel with adb before booting it. Do something
like:
adb -w /vmunix.new << FOO
nclist?D -- display old value
nclist?W 0t500 -- change to decimal 500
FOO
Shut down the system with /etc/fasthalt, then boot it from the new
kernel (b /vmunix.new). If it comes up and doesn't crash, things are
in pretty good shape.
Now to set up the slip link, compile "slattach" on both ends, then make
sure the serial line between the machines is working (e.g. using "tip"
on both ends, you should be able to type back and forth to each
other). You will need to assign a network number (or subnet number, if
your machines are using subnets) for the serial link itself; it is
treated as a network with two hosts on it. Update /etc/networks on
both systems with this number, and create new names for your two hosts
(typically the original hostname plus a suffix like "-slip", e.g.
"hoptoad-slip") in /etc/hosts, which have addresses on this new
network. For example:
/etc/networks:
sun-ether 192.9.200 sunether ethernet localnet
sliplink 192.33.33
srinet 128.18
/etc/hosts:
# The Ethernet at one end
192.9.200.1 hoptoad hop toad loghost mailhost
192.9.200.2 polliwog polli wog
192.9.200.3 tadpole tad pole
# The SLIP link
192.33.33.1 polli-slip
192.33.33.2 ws1-slip
# The Ethernet at the other end
128.18.523 fs1
128.18.533 ws1
128.18.534 ws2
128.18.535 ws3
After updating these files at both ends, if you use the Bellow Pages,
remake the database with (cd /usr/etc/yp; make hosts networks).
Then run "slttach" on both ends, specifying the tty line, YOUR machine's
name on the SLIP network, the other guy's name on the SLIP network,
and the baud rate, e.g.:
polliwog# slattach ttyb polli-slip ws1-slip 19200
ws1# slattach tty04 ws1-slip polli-slip 19200
You don't have to do these at the same instant. At this point you
probably have an IP connection going; you should be able to see it
by doing a "netstat -i".
Next, try it with "ping". Watch the modem lights if you can, while it
pings. On polliwog you would ping "ws1-slip". On ws1 you would ping
"polli-slip". If that works, you can try an rlogin, telnet, or ftp.
If it doesn't work, you should be able to see the packets go out over
the modem "SD" (send data) light, but nothing will probably be coming
back in on RD. That means the other end is not answering, so look
there -- try netstat -i, ping from that end, etc. Be sure you specified
the right parameters on both ends.
You can pass packets now, but hven't figured out routing. If you are
running "routed" on both machines, routed should figure out the routing
for you. Within a minute or two of when the link comes up, a "netstat -r"
should show a route to the remote Ethernet via the "sl0" interface on your
machine. If you aren't running routed, you'll need to do "route add"
commands.
If one end is on the Arpa Internet, there are further complications.
If any of your network numbers aren't known to the core gateways, other
hosts will not be able to route packets to you. The main Internet
gateways *do not* automagically notice new networks and figure out the
routes, like Berkeley "routed" does. Somebody with the authority to
tell them, has to tell them that you exist. If your SLIP network and
your remote Ethernet, if any, are both subnets, then the normal Internet
routing will get your packets back to your subnet, and you just have to
make sure that the gateways inside your subnet know how to get to you.
If all your gateways run "routed" this should happen automatically.
You may want to add a "default route" on your remote Ethernet hosts
which routes packets for any random network through the host on the
Arpanet end of the SLIP link; this way you won't have to run a routing
daemon to be able to talk to any network on the Internet.
If the link goes down, you will probably have to reboot both systems
to get them back in sync. The slip drivers are not robust enough, and
can crash the system if you try to re-establish a link after you had
one running. I think it'd be great if you fixed this...I don't know
enough about what is going on to do so.
I have tried running NFS over a SLIP link with Telebit 18,000 baud
modems. It hung or crashed my systems until I allocated a bunch more
"clists" (character queues for serial ports), as described under kernel
configuration above. I did get NFS to work over the SLIP link though.
It was not very fast, it didn't feel much like a disk, but if you are
careful what you touch, it can be better than FTP and rcp for moving
things around. I recommend unmounting things when not in use, lest
people stumble on them and create immense amounts of traffic
inadvertently. For example, most peoples' systems run a "find" command
that scans the whole file system once a night. I recommend mounting
file systems "intr" and with small blocks (512 bytes) and long timeouts;
see the "mount" command man page.
Good luck! This has been typed at about a month's remove from the last
time I did it, so there may be errors in the procedures. If so, please
send me email (gnu@toad.com, or hoptoad!gnu). Feel free to pass it on
to other people. Mark owns the code and allows it to be distributed;
and this description, by me, is in the public domain. Also, let me know
if you successfully set up a SLIP link with these instructions -- or,
even better, figure out how to let dialin users set up and tear down SLIP
links on demand.
John Gilmore
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com
Love your country but never trust its government.
-- from a hand-painted road sign in central Pennsylvania