From 039b85dd43b56e9a07958fc0e269a7182143b408 Mon Sep 17 00:00:00 2001 From: Tobias Brunner Date: Mon, 28 Aug 2017 19:12:16 +0200 Subject: 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. --- src/libcharon/plugins/kernel_pfroute/kernel_pfroute_net.c | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'src/libcharon/plugins/kernel_pfroute/kernel_pfroute_net.c') diff --git a/src/libcharon/plugins/kernel_pfroute/kernel_pfroute_net.c b/src/libcharon/plugins/kernel_pfroute/kernel_pfroute_net.c index da7ae472d..e1f10e93f 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); -- cgit v1.2.3