Subject: Re: SLIP/serial driver Problem?
To: None <tech-net@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 02/04/2004 21:43:36
>> Please share some steps that are as simple as ...
>> slattach -l -h -s 115200 /dev/tty01
>> ifconfig sl0 192.168.10.10 192.168.10.11
> That's only side, correct?
Sure. The other side is the same, except with the IPs swapped and
possibly a different tty device name.
> So, to set up PPP over a "wire", you run, on the remote end,
> something like:
How can I tell which end needs to be "the remote end"?
> pppd tty01 115200 crtscts local silent persist noauth 192.168.10.10:
> and on the local
> pppd tty00 115200 crtscts local persist noauth 192.168.10.11:
> 1) Adjust the com port and bit rate to your situation, of course.
Of course. (As much needs to be done in the SLIP case anyway.)
> 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.
Whoa. What makes you think you have any idea which is started first?
Remember, the link needs to come back, unattended, whenever _either_
end reboots (and the other is thus "up first") or, for that matter, if
the wire is disconnected for an hour or so without either end
rebooting. SLIP meets these challenges splendidly.
I actually think this is an excellent example of how complexity can
make simple tasks hard. SLIP Just Works in this circumstance _because_
it's so simple; it's too simple to be broken by things going away and
coming back in unhelpful orders. The complexity of PPP (put there for
good reason, for things like detecting link failures) actually gets in
the way here, where you don't _want_ things like detecting link
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML firstname.lastname@example.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B