From 6fa203b8d4dfdaad586a3b056cb1ff1318f6e643 Mon Sep 17 00:00:00 2001 From: Martin Willi Date: Fri, 24 Oct 2014 15:21:11 +0200 Subject: kernel-pfroute: If a new interface appears, slightly delay address enumeration On OS X 10.10, when installing a virtual IP on a tun device, there is a chance that a RTM_IFANNOUNCE is sent before the IP is ready on that link when calling getifaddrs(). As we don't get an RTM_NEWADDR event either, that race lets us miss the virtual IP install event, failing the add_ip() call. --- src/libhydra/plugins/kernel_pfroute/kernel_pfroute_net.c | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'src/libhydra/plugins/kernel_pfroute/kernel_pfroute_net.c') diff --git a/src/libhydra/plugins/kernel_pfroute/kernel_pfroute_net.c b/src/libhydra/plugins/kernel_pfroute/kernel_pfroute_net.c index 26fae0d6b..0f7802270 100644 --- a/src/libhydra/plugins/kernel_pfroute/kernel_pfroute_net.c +++ b/src/libhydra/plugins/kernel_pfroute/kernel_pfroute_net.c @@ -830,6 +830,15 @@ static void process_link(private_kernel_pfroute_net_t *this, DBG1(DBG_KNL, "interface %s deactivated", iface->ifname); } } +#ifdef __APPLE__ + /* There seems to be a race condition on 10.10, where we get + * the RTM_IFINFO, but getifaddrs() does not return the virtual + * IP installed on a tun device, but we also don't get a + * RTM_NEWADDR. We therefore could miss the new address, letting + * virtual IP installation fail. Delaying getifaddrs() helps, + * but is obviously not a clean fix. */ + usleep(50000); +#endif iface->flags = msg->ifm_flags; repopulate_iface(this, iface); found = TRUE; -- cgit v1.2.3