On (05/01/09 16:16), James Carlson wrote: > Sowmini.Varadhan at Sun.COM writes: > > - Jim pointed out some issues about IFF_UP's history which were the > > reasons for reusing IFF_UP as the enable/disable flag for DAD. > > The ramification of this choice is that one needs to mark an interface > > as "up" to retry DAD, while the kernel will keep marking it down > > as long as DAD keep failing. > > I'm not quite sure what you meant here, but there's no need for > administrative action to recover a DAD-failed interface. The system > runs a timer on all DAD-failed interfaces and periodically tries to > bring them back up. This is the solution to the "closet server" > problem described in the design document.
Yeah, I know. But (while you were on vacation) the argument was made that the admin might be too impatient to wait for the restart timer thread and would then "need" to restart DAD at will. > > We should provide some library function that takes a sockaddr as > > input and returns a logical interface name as output to help out > > applications that have to muddle through GLIFCONF today. > > That's a subset of what BSD's if_addrlist gives you. True. > I guess a new function could be added as well, but if nobody uses it > on other platforms, why bother? I was thinking of some application like quagga that hears about a physical interface and an address on a routing socket, and then wants to, say, find the netmask of that address.. the "addr_to_lif()" function that I proposed would save this application the trouble of marching down the addrlist and doing comparisons. It would just be a minor helper function, of course. --Sowmini
