>I've been using dip-uri 337 for some time now quite successfully for my
>SLIP connection. Now I'd like to use it for PPP. Except the code does
>not support PPP. The ppp.c source just says: "PPP protocol not available
>yet"
Fred N. van Kempen indicated that he would like to merge the pppd code
into dip for Linux/PRO. He did not give any time schedules.
Quote:>I have developed a fairly complex call-back dip-script that I'd just as
>soon not like to re-invent with a new CHAT program. I'm looking for
> (1) Additions to dip to support ppp. This doesn't look like it
> should be too difficult, given that ppp already exists. Anyone done
> it?
You are welcome to do this. I have very strong reservations about
doing this as I don't feel that this is a Good Thing (tm). However, if
this is what you want, then be my guest and do it.
If you truly believe that "it doesn't look like it should be too
difficult", then I respectfully suggest that you go back and look
again.
Quote:> (2) An example from some PPP user of a complex callback CHAT script.
It takes two scripts to implement a callback. The first one connects
with the remote peer and does the initial identification. The second
one waits for the callback and does the secondary identification when
it arrives.
You need to add "CLOCAL" to the termios' c_local flags in the chat
program. Without it, the second script will not work because there
will not be a carrier signal.
I don't want to put this in as "standard" because the non-callback
systems (which are still the majority of users) should not use it. In
those cases, you want the chat script to abort should the carrier
fall. However, an option might not be a bad idea.
On the general subject of chat or dip . . . .
The pppd process does not actually connect to anything. It requires
that the connection be in place before it starts its protocol
exchanges. As such you may use either the "connect" parameter, which
causes pppd to fork some external process to do the connection; or
some external program which will have made the connection prior to
running pppd.
Any process which connects the modem to the remote system and does
the initial sequences to start ppp on the remote will suffice. This
works just as well from a human who must manually dial the rotary
telephone and enter a sequence of characters to any automated method
that you can envision. You are not bound into using chat or dip or
anything else.
Some people have used dip for the purpose of running the connect
sequence. I have no problem with that. However, as connect script
processors go, dip is fairly bloated to just being used as a "chat"
replacement.
The taylor-UUCP (on prep.ai.mit.edu in the gnu directory) contains a
program called "xchat". (No, that is not an "X-windows" version of
chat. :) It works in most of the major respects as does dip.)
Of course, if you want total flexibility and power, the best tool is
tcl and expect.
--