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 da7ae472dedfe1648fcb765e2b0510959f23cdf4..e1f10e93f686688fbb091a1a4f1db88f2283b82c 100644 (file)
--- 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);