SLIP without kernel modification

[John Chambers]

In article <128234 at tyrell.stgt.sub.org>, rodney at tyrell.stgt.sub.org (Rodney Volz) writes:
> Is there a way to speak SLIP to a remote machine, if you do
> not have the possibility to rebuild the kernel with a
> slip-driver in it? I've RTFM to find out, whether there's
> a way to feed raw IP packets to a host, but nothing...

Well, in general, *something* needs to be added, because there is  the
problem  of how you persuade the IP package in the kernel to hand over
the packets that need to go out the SLIP port.  But that something  is
not necessarily a SLIP driver.

Recently, I got my hands on a driver for Ultrix that is something that
I've wished was in the IP package from the  start.   It's  called  the
"PNI" driver, which stands for Pseudo-Network Interface. What it is is
a network equivalent to a pty:  It looks like a network interface from
one  side,  so that IP will talk to it and trade packets with it.  But
instead of talking to hardware, its  other  side  is  a  special  file
(i.e.,  /dev/pni*)  that  can be opened by a process.  The process can
assign an IP address to the pseudo-device, and  IP  will  then  hapily
hand  the driver any packets for that address; the driver buffers them
until the process does a read.  The process can write a chunk of bytes
to the device, and the chunk is passed to IP as a packet.

When I linked this driver into  my  Ultrix  workstation,  it  took  me
roughly  one  day  to  implement SLIP on top of it, using the RFC as a
guide and some nearby SLIP implementations for regression testing.   I
then  looked  into doing fun things like data compression, statistics,
etc.  A couple days later I had roughly 2-1 compression of  X  packets
going across the line.  And so on.

This  approach  has  some  real  advantages,  despite   some   obvious
performance  hits due to the task switching.  For instance, the Ultrix
4.1 SLIP isn't allowed to lower DTR and hang  up  the  phone  on  SLIP
links.   The  code is there in the driver, and it works fine on Ultrix
3.1.  But when you make the ioctl to lower  DTR  on  4.1,  the  kernel
rejects  it  outright  ("Invalid Argument"), and doesn't pass it on to
either the SLIP or the TTY driver.  With the PNI  driver,  the  kernel
doesn't  realize  that the port is doing SLIP.  It just sees a process
with /dev/pni0 and /dev/tty03 open, but it has no suspicion that  they
are  related,  so it doesn't interfere with useful things like hanging
up the phone.   (True, this is a bug in Ultrix 4.1, but without kernel
source, what can I do?  Complain, that's what I can do.  Lotta good it
does.  SLIP is unsupported.)

I have no idea whether such a pseudo-interface is available for  other
systems.  I wish they were. I'd like to get the opportunity to make it
available elsewhere, but as usual low-speed networks  like  the  phone
system  aren't  sexy  enough to get the funding they deserve.  Dealing
with the kernel for things like SLIP is a real pain, since TFM  is  of
little  benefit  and  you  invariably  have  to  wade through piles of
insults to ferret out the facts concerning things like TCP/IP...

-- 
All opinions Copyright (c) 1991 by John Chambers.  Inquire for licensing at:
Home: 1-617-484-6393 ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc 
Work: 1-508-486-5475 {sppip7.lkg.dec.com!jc,ub40::jc}