From: Martin Willi <martin@revosec.ch>
Date: Fri, 24 Oct 2014 13:21:11 +0000 (+0200)
Subject: kernel-pfroute: If a new interface appears, slightly delay address enumeration
X-Git-Tag: 5.2.2~14^2~3
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=6fa203b8d4dfdaad586a3b056cb1ff1318f6e643;p=thirdparty%2Fstrongswan.git

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.
---

diff --git a/src/libhydra/plugins/kernel_pfroute/kernel_pfroute_net.c b/src/libhydra/plugins/kernel_pfroute/kernel_pfroute_net.c
index 26fae0d6b4..0f78022702 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;