🚀 go-pugleaf

In article <4970@balrog.ctron.com> crowell@ctron.com (Chris Crowell) writes:
>All of the PPP implementations I have seen for Sun have executed in
>kernel space.  Are there implementations that execute in user space ? Can PPP
>operate in user space ?

The KA9Q NOS software can be coaxed to run on a Sun.  There are UNIX
porting kits around for older versions (which don't support PPP); it
is a modest amount of work to adapt these to work with newer versions
of NOS (which do support PPP).  I did this for System V R3.2.

This sort of setup is fine for outbound telnet and for FTP.  It is a
self-contained program which does its own multi-processing, though, so
don't expect it to interface with other network software.  To do that,
you need to either put PPP in the kernel, or use a "tunnel driver" like
MorningStar does with their PPP (a pseudo-device driver which allows a
user process to pump IP packets into and out of the kernel).

MorningStar's latest version of the tunnel driver for the Sun is
dynamically installable, and the PPP software which runs with it is
highly configurable and robust.  It's a commercial product, but it is
worth the bucks if you are going to be using PPP on a regular basis.

		-Ed Hall
		edhall@rand.org

edhall@rand.org (Ed Hall) writes:
>don't expect [KA9Q NOS] to interface with other network software.  To
>do that, you need to either put PPP in the kernel, or use a "tunnel
>driver" like MorningStar does with their PPP (a pseudo-device driver
>which allows a user process to pump IP packets into and out of the
>kernel).

If your computer already supports SLIP, you can do this with a PTY. I
wrote a small user-level program that just tunnels bytes between a PTY
and a TTY. Running SLIP through this "bridge" adds a few copy
operations between kernel and user memory. This gave me no measurable
decrease in throughput (using ftp), and only little longer response
times (using ping). My TTY line does 9600 bit/s TTY line. The slow TTY
line is the real bottleneck here, so you could probably do this on
much slower computers than my HP 9000/400 running HP-UX 8.0 and
IBM-compatible 486 PC running SCO UNIX.

I did this only for some experiments, and as an exercise, and didn't
use it later. The problem I never solved was opening a PTY with a
well-known name. The SLIP implementation used (HP-UX PPL) wants the
name of the underlaying SLIP device to be written in a file, and I
don't know the name of the PTY until I have successfully opened it. If
a window system grabbed my favorite PTY, I would have to use another.

I never tried to translate between SLIP on the PTY and PPP on the TTY,
so I cannot know how much overhead that would have caused.

Is anybody from Hewlett Packard out there? How long do we have to wait
for HP's PPL product to implement the PPP protocol? It has been a
promise for a long time now.
-- 
Lars Aronsson, SECTRA AB, Teknikringen 2, 583 30 Linkoping, Sweden