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.
This commit is contained in:
parent
ab7d5e32d3
commit
039b85dd43
|
@ -864,6 +864,11 @@ static void process_link(private_kernel_pfroute_net_t *this,
|
||||||
.flags = msg->ifm_flags,
|
.flags = msg->ifm_flags,
|
||||||
.addrs = linked_list_create(),
|
.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))
|
if (if_indextoname(iface->ifindex, iface->ifname))
|
||||||
{
|
{
|
||||||
DBG1(DBG_KNL, "interface %s appeared", iface->ifname);
|
DBG1(DBG_KNL, "interface %s appeared", iface->ifname);
|
||||||
|
|
Loading…
Reference in New Issue