Subject: Re: SLIP/serial driver Problem?
To: Jeremy C. Reed <>
From: Frederick Bruckman <>
List: tech-net
Date: 02/04/2004 10:43:58
On Tue, 3 Feb 2004, Jeremy C. Reed wrote:

> On Tue, 3 Feb 2004, William Allen Simpson wrote:
> > Goodness gracious, isn't it beyond time to remove SLIP support?

Although I don't much care of SLIP myself, I wouldn't go quite that
far. As has already been pointed out, PPP is too big for the install
kernels, which is a good enough reason to keep SLIP around, IMHO.

> >  PPP should "just work".
> Please share some steps that are as simple as ...
>   slattach -l -h -s 115200 /dev/tty01
>   ifconfig sl0

That's only side, correct?

> ... but using ppp instead and without any configuration files adjusted.
> I have only used PPP with ppp daemon for providing modem dial in and for
> dialing out. And I'd like to learn more about using it as a slip
> replacement.

First of all, you should realize that the contents of the "/etc/ppp"
directory are only for convenience; you can just as well put all the
contents on the command line. So, to set up PPP over a "wire", you
run, on the remote end, something like:

  pppd tty01 115200 crtscts local silent persist noauth

and on the local

  pppd tty00 115200 crtscts local persist noauth

1) Adjust the com port and bit rate to your situation, of course.

2) The "crtscts" assumes that you have the null modem fully wired for
hardware handshaking. "local" simply ignores the modem control lines;
if you want "pppd" to notice when the other side is powered down, you
could wire the CD lines to V+ (and use "modem"), but that isn't done
with a standard null modem.

3) Both hosts should have "persist"; the first one started gets
"silent" so that it doesn't start doing LCP before the other is up,
and so fail.

4) "noauth" on each side meets your challenge of "no config files",
though it would be simple enough to get the hosts to authenticate to
each other.

5) Finally, the IP addresses; it's the colon ":" that distinguishes
them syntactically from a bit rate; you can also supply the address of
the remote, by placing the colon at the beginning of the IP address.