Bug #5709
closeddpinger fails to start on IPv6 IPs considered "tentative", often breaking IPv6 gateway monitoring
0%
Description
replacing inadvertently deleted #5696
For some period of time during boot, IPv6 IPs are considered "tentative" by the OS. For instance, ifconfig output like the following two examples (one static WAN, one gif tunnel).
inet6 2610:160:11:ffff::11 prefixlen 64 tentative inet6 2001:470:ffff:71::2 --> 2001:470:ffff:71::1 prefixlen 128 tentative
When dpinger starts with ifconfig showing that state (which is every boot in many IPv6 configurations), it immediately exits with no logging. Launching it with truss in gwlb.inc shows the following output.
bind(3,{ AF_INET6 [2001:470:1f0e:71::2]:0 },28) ERR#49 'Can't assign requested address' writev(0x2,0x7fffffffe0c0,0x4) = 37 (0x25) write(2,"cannot bind send socket\n",24) = 24 (0x18) process exit, rval = 1
This leaves no dpinger processes running for IPv6 WANs. Running setup_gateways_monitor() after boot starts all dpinger instances correctly, but that doesn't happen without user-intervention.
Aside from fixing the problem at hand here, this type of error condition should really make it to the logs rather than having to change it to launch under truss to figure out the problem.
Issue #5696 has been updated by Renato Botelho.
Opened a issue upstream just to track it - https://github.com/dennypage/dpinger/issues/16
Issue #5696 has been updated by Jim Thompson.
IN6_IFF_TENTATIVE is set while DAD (duplicate address detection) is running.
probably also want to test for IN6_IFF_DUPLICATED