PPPD: New ip-{up,down} script handling
Some of you may have seen my earlier message on this subject. I have done
some hacking to pppd, and have come up with a better arrangement.
Pppd now has six states that it enters into during a connection attempt. They
are as follows.
state script to run old method
==================================================
initializing pppd_initializing
connected pppd_connected
online pppd_online ip-up
offline pppd_offline ip-down
disconnected pppd_disconnected
idle pppd_idle
initializing
Right after the serial device is opened, but just before the
connection script is run. In the future, this could be used for an
external connection program.
connected
Just before link negotiation begins after the connection has
succeeded.
online
The link is up and running smoothly.
offline
The link has been terminated, either by "user request", or by some
fatal hardware error(modem hangup, etc.).
disconnected
The disconnect script(if available) has run.
idle
This state in active while pppd is delaying for redial(ie holdoff
time).
At each point, pppd runs /etc/ppp/debug(this name will be changed), with the
first parameter as "script to run", the second as the device name. Pppd
waits for each script to finish before continuing. I will finish modifiying
the program to pass on the interface name, etc., where appropriate.
The external script system is setup like init.d and rc?.d. The directory for
all scripts is "/etc/ppp/scripts.d". The runlevel dirs are "init.d",
"cnct.d", "online.d", "offline.d", "discnct.d", and "idle.d". A program,
"ppp-update.d", is used to facilitate managing the links. Its syntax is like
update-rc.d(really just a hacked version).
I could have this done by midnight monday, but I don't want something this
radical going in so quickly. It will wait for 2.1.
Adam
ps:
When in demand dialing mode, pppd enters the "initializing" phase, and
then waits. Please be sure to take this into account when scripts are run.
Also, I have yet decided how I want to handle an "initializing failure". I
also might implement a "pre-offline" state, run just before negotiating the
link to go down. This would allow things link updating a dyndns ip
to point to oblivion, so that no-one else would get your packets. Obviously,
if a hardware error occured, then there would be no delay between this and the
real "offline".
ps2:
Re: the code freeze at midnight monday. Does that mean early monday
morning(sunday night), or late monday night(tuesday morning)?
--
E-mail the word "unsubscribe" to debian-devel-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@lists.debian.org
Reply to: