On (04/24/09 22:15), Peter Memishian wrote: > > > I'm not sure what "sending IFF_UP" above means. > > > > on ifm_flags in routing socket messages. > > I'm still not sure what you're getting at. Today, NEWADDR is generated > once an address becomes IFF_UP, and DELADDR is generated once it's no > longer IFF_UP.
Correct, so why bother to include the flags at all (since the only info the routing socket message can have is "ce1", and not something like "ce1:5", so that the flags give misleading info)? Moreover, I tried some experiments, and noticed something I did not expect: if I do something like # ifconfig ce1 addif 12.1.2.3/24 no routing socket messages are intercepted by "route monitor", but if I do "ifconfig ce1:1 unplumb", route monitor gets informed (about an address removal whose addition it was never told about). Also, both "ifconfig ce1:1 down" and "ifconfig ce1:1 unplumb" generate identical routing socket messages. So as far as routing socket listeners concerned, there's no way to distinguish (assuming that they really need to - do they?) between a downed address and a deleted address without resorting to ioctls (and given that routing sockets don't divulge logical-interface info, this means starting from GLIFCONF). then this gets worse: if (and only if) I down the 0'th address, an RTM_IFINFO is generated as well, even though the other logical interfaces are alive and kicking. I think that just generating a DELADDR for the address (even the 0'th one) would be sufficient. And having something like RTM_IFANNOUNCE to track plumb/unplumb events would help track interface (ill) liveness. > This behavior makes sense to me and I think it would be > more consistent (and simpler for applications) to have the same behavior > by default with SIOCGLIFCONF. Hiding downed addresses from GLIFCONF is a Good Thing, but maybe we could drop the flags from NEWADDR as well. And if we really want to keep the downed-but-not-quite-deleted addresses, then is it worthwhile to have a separate system-call (maybe using additional flags, as with ipmp's solution for test addresses) --Sowmini _______________________________________________ networking-discuss mailing list [email protected]
