On Wed, 2004-10-13 at 23:14, Richard A Nelson wrote: > I don't see how we can get this kind of support without ppp and dhcp > support... The two would be very similiar (the potential to get the > same address, or a new one).
I am not sure I understand what you mean here. Are you saying that there is no point in ifupdown providing the "up" command facility if the "up" commands don't get run on reconnect as well as initial connect? That is certainly something worth discussing. Currently ifupdown (experimental[1]) runs "up" commands and scripts after bringing up any kind of interface. That reflects its design: ifupdown is not an active network management program; it assumes that when it brings an interface up, it stays up. In order to force PPP and DHCP interfaces to conform to this model, ifupdown (experimental[2]) runs pppd with the "persist" option and other DHCP clients with options that tell them to keep connections up and to keep retrying the connection if it goes down[3] until they are told (by ifdown) to bring the connections down. [1] As I have mentioned before, the testing/unstable ifupdown runs "up" commands too early in the case of PPP interfaces. [2] The testing/unstable ifupdown does not use the "persist" option. [3] Actually this is not entirely true. See #263749 and #253472. If we want a system that will run common hook scripts on reconnects then we can certainly hack the feature into ifupdown. However, our time might be better spent writing a replacement for ifupdown that is designed from the ground up to handle dynamic networking. > It would take some thought to handle all the possibilities properly > but the end result would be *very* nice. I've tried a few times, > and wound up with scripts in ppp, dhcp, and network - all modelled > similiar to the DHCP state management. I have also had to deal with this when I made the resolvconf package: I had to write different hook scripts for each of the DHCP clients, pppd and ifupdown. It took a long time to debug them all. -- Thomas Hood
