On Tue, Feb 25, 2014 at 08:56:52PM +0000, Pierluigi Rolando wrote:
I'll see if I can come up with something better, no promises though.
Quick follow-up for BIRD developers: what's the point of the IF_TMP_DOWN state in the first place? I think I understand its usage in the 'too much has changed' case of if_update, but not why it stays set for interfaces with no addresses.
Hi The reason for IF_TMP_DOWN during initial scan is probably that interface notifications to protocols are grouped - protocols are notified about new interfaces after initial scan is complete and addresses of interfaces are known. Your analysis of the problem has one error - the interface is not kept in IF_TMP_DOWN state when it has no address. IF_TMP_DOWN is set during initial scan, then it is cleared in if_end_update(), but the interface without IP address is held down (no IF_UP) because of if_recalc_flags(). Then, when a new address appears, IF_TMP_DOWN is set again for the interface, probably because of ifa_recalc_primary() in ifa_update(), and now it is not cleared (which is a bug), because it was set during asynchronous update, so there is no if_end_update() like in periodic scans. Similar problem is when the IP address is there but the primary IP address changed, this also causes IF_TMP_DOWN until the next scan. This could be probably fixed by calling if_end_partial_update() after asynchronous notification for related interfaces. The mentioned issue that an interface without addresses shouldn't be artificially held down is true, but it is currently assumed by protocols, so it would require some further code revision to fix it. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."