From: Tobias Brunner <tobias@strongswan.org>
Date: Mon, 28 Aug 2017 17:12:16 +0000 (+0200)
Subject: kernel-pfroute: Delay call to if_indextoname(3) when handling RTM_IFINFO
X-Git-Tag: 5.6.1dr3~2
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=039b85dd43b56e9a07958fc0e269a7182143b408;p=thirdparty%2Fstrongswan.git

kernel-pfroute: Delay call to if_indextoname(3) when handling RTM_IFINFO

It seems that there is a race, at least in 10.13, that lets
if_indextoname() fail for the new TUN device. So we delay the call a bit,
which seems to "fix" the issue. It's strange anyway that the previous
delay was only applied when an iface entry was already found.
---

diff --git a/src/libcharon/plugins/kernel_pfroute/kernel_pfroute_net.c b/src/libcharon/plugins/kernel_pfroute/kernel_pfroute_net.c
index da7ae472de..e1f10e93f6 100644
--- a/src/libcharon/plugins/kernel_pfroute/kernel_pfroute_net.c
+++ b/src/libcharon/plugins/kernel_pfroute/kernel_pfroute_net.c
@@ -864,6 +864,11 @@ static void process_link(private_kernel_pfroute_net_t *this,
 			.flags = msg->ifm_flags,
 			.addrs = linked_list_create(),
 		);
+#ifdef __APPLE__
+		/* Similar to the issue described above, on 10.13 we need this delay as
+		 * we might otherwise not be able to convert the index to a name yet. */
+		usleep(50000);
+#endif
 		if (if_indextoname(iface->ifindex, iface->ifname))
 		{
 			DBG1(DBG_KNL, "interface %s appeared", iface->ifname);