Peter Memishian writes: > > If you change the way DHCP treats ~IFF_UP, then what are the specific > > semantics? Is it possible for DHCP to use DLPI while the interface is > > down to establish a new address and turn IFF_UP back on, or are we > > "stuck" in that state until the address ages away? (My guess is that > > it's the latter.) > > In Nevada, DLPI isn't used anymore by DHCP except as a transient means to > get the hardware address and ARP type -- so I don't think DLPI factors > into the equation.
I know; I'm asking about what's intended. When DHCP starts normally, the interface is "down" and DHCP marks it as "up" so that it can do its thing. I'm really asking about when DHCP knows it ought to do that and when it should leave the administrator's IFF_UP flag (or lack thereof) alone. > > I guess I'm saying I'd be supportive of going _further_ than just > > IFF_UP, but if that's the only change you want, then I'd support that. > > I think you bring up a good point, and I agree that the abandon mechanism > is probably too hair-trigger. At one end of the spectrum, there are cases > (such as unplumb or change of IP address) where abandoning seems the only > reasonable behavior. At the other end, there are cases like clearing > IFF_UP or tweaking the netmask where there's no clear indication that > anyone has asked DHCP to step aside, and in fact its urge to run gets in > the way. Yep. Though I'd say that "unplumb" is the only clear unrecoverable there. Even with an address change, *I* would have expected DHCP to ignore the change on the interface itself entirely unless (and until) the server decided to supply a different address. In other words, change of lease data from the DHCP server means "apply these changes now to the system." But otherwise DHCP isn't in the business of trying to make sure that the interface matches what's set. It's a configuration mechanism, not a nanny. An analogy would be to routing. We expect the routing daemons to check the system state at start-up, and we expect them to apply changes to the system as they learn new things, but in a steady-state position, you should be able to add or delete routes without the routing daemon getting all huffy about it. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
