rodney@tyrell.stgt.sub.org (Rodney Volz) (06/07/91)
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...
Any suggestions?
-Rodney
--
Rodney Volz - 7000 Stuttgart 1 - FRG
============> ...uunet!mcsun!unido!gtc!aragon!tyrell!rodney <=============
rodney@tyrell.gtc.de * rodney@delos.stgt.sub.org * rodney@mcshh.hanse.de
\_____________ May your children and mine live in peace. ______________/jc@minya.UUCP (John Chambers) (06/19/91)
In article <128234@tyrell.stgt.sub.org>, rodney@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}
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (06/22/91)
In article <800@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: > In article <128234@tyrell.stgt.sub.org>, rodney@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? > 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: I built something similar to this a few years back. Very useful thing. In our case, though, the idea was to shove IP packets through a network of DECnet-only routers. So I had the psi (my name for it) interface talk to a program that sent the packets out over DECnet connections, and the process on the other end did the reverse transformation.... Later, I built a user-level program to run it as a SLIP link. I considered using it to circumvent a brain-damaged administrative nightmare of a router (they'd implemented a packet fence that dropped most useful services, like mail and finger, on the floor, but allowed connections on high-numbered ports. (There is something very appealing about using a TCP connection as an IP packet transport :-) Never did, because the packet fence came down before the irritation level got sufficient to prod me into setting it up. > I have no idea whether such a pseudo-interface is available for > other systems. My driver works on a couple of old versions of Ultrix and on 4.3. I'm told it works on relatively recent Ultrices. It probably wouldn't be much effort to port it to anything that provides a Berkeleyish driver interface. > 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... UTSL...and if you don't have TS, scrap what you have and get a real OS! (Only half a :-), and that half only because there seem to be no sane hardware manufacturers these days....) I've put a copy of if_psi.c up for anonymous ftp on 132.206.1.1; there's also if_psi.README, which is the README from the IP-over-DECnet stuff I mentioned above; I included it because it describes installing if_psi into the kernel. (It also describes setting up the DECnet-IP stuff too; just ignore that.) I can also mail copies if necessary.... der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
mah@wu-wien.ac.at (Michael Haberler) (06/26/91)
In article <800@minya.UUCP>, jc@minya.UUCP (John Chambers) writes: |> 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 I've been looking into Compressed SLIP for Interactive/386 and came to the same conclusion for different reasons. While theoretically elegant (one could imagine pushing a SLIP framing module onto a tty, and then a VJ compressor on top, and link this under the IP multiplexer at runtime) this doesnt work because the Lachman netd (the program which sets up the STREAMS stacks for IP) doesnt allow pushing STREAMS modules, only linking them under/over Multiplexer modules. Great idea, I though, neat, simple and wrong :-( So the alternatives are to munge evrything from tty access, slip framing to VJ compression into a single STREAMS device driver, which I'm lacking information to do at the tty level. Also, this looks like serious debugging ahead. The other alternative is something like you mentioned, and I finally have something close to that for ix/386. It's based on a SLIP driver done by John Joannides at cmu. It does the same thing-go back to userland for SLIP framing and such. What I have is'nt ready for release yet, but I plugged a memory leak and reverse-engineered some of the socket ioctls for network interfaces. So a dedicated hacker should send me mail. - michael -- Michael Haberler mah@wu-wien.ac.at, mah@awiwuw11.bitnet University of Economics and Business Administration A-1090 Vienna, Augasse 2-6 Biz: +43 (1) 31336 x4796 Fax: 347-555 Home: +43 (1) 961-679 (voice & fax) D-Netz: +43 (663) 811-056