Created attachment 149611 [details] Retry NET_RT_IFLIST sysctl. rtadvd exits after printing the message: rtadvd[41840]: <update_ifinfo> sysctl: NET_RT_IFLIST get failed The NET_RT_IFLIST sysctl required buffer size can change between the request for the size and the request for the data. getifaddrs handles this by retrying the sysctl several times. I copied the comment and looping from lib/libc/net/getifaddrs.c to have rtadvd behave like getifaddrs. rtadvd should probably also be changed to not need to call the sysctl for every message if the required info can be obtained by other means. Issue replicated in an environment with dhcpcd for DHCPv6-PD giving an address to a lan interface and a tun interface. Restarting dhcpcd can sometimes trigger the problem. dhcpcd adds a global ipv6 addresses and routes to the interfaces triggering RTM_NEWADDR and RTM_ADD. rtadvd calls update_ifinfo on RTM_NEWADDR and RTM_ADD. The likely scenario is: dhcpcd adds an address for the lan interface. rtadvd receives RTM_NEWADDR for the lan interface. rtadvd calls the sysctl to get the required size. dhcpcd adds an address for the tun interface. size changed. rtadvd calls the sysctl to get the data size with small buffer.
+1 on this one. This happens with a near consistency when new epair devices get created on my 11.0-RELEASE-p7 system.
This is happening on startup for me when dhcp6c is pulling addresses from Comcast and assirgning them to vlan interfaces, thereby shutting down rtadvd entirely and leaving me without any IPv6 connectivity at all.
+1 also happening for me on 12.0-RELEASE-p3 amd64: rtadvd[62952]: <update_ifinfo> sysctl: NET_RT_IFLIST get failed Seems to be happening quite frequently as I'm on a DSL line with forced reconnect by ISP every 24 hours, which triggers dhcp6c and getting a new dynamic IPv6 prefix which is then assigned to the re0 and tun0 interfaces on which rtadvd operates.
Reset assignee, timeout (2 years) @Hiroki If you can still take care of this issue, please re-assign yourself @All If the existing patch (attachment 149611 [details]) no longer applies against CURRENT, it would be great if someone could rebase it to HEAD and confirm that it still resolves the issue for their use case
Created attachment 203750 [details] Retry NET_RT_IFLIST sysctl The original patch still applies to 12-RELEASE and 13-CURRENT (r346321). I uploaded an updated patch that defines the "ntry" variable in the same line as "error" instead of on a separate line. The rest of the changes are the same.
I've applied the original patch against 12.0-RELEASE eight days ago and did not have another rtadvd outage since then. Before this, the process seemedt to never make it more than 3 days in my VDSL dialup setting with 24h disconnects from ISP side.
A commit references this bug: Author: markj Date: Tue Apr 30 14:44:40 UTC 2019 New revision: 346960 URL: https://svnweb.freebsd.org/changeset/base/346960 Log: Retry upon NET_RT_IFLIST sysctl failure. Port the logic used by getifaddrs(3) to handle the case where NET_RT_IFLIST returns ENOMEM, which can occur if the list size changes between the buffer allocation and sysctl read. PR: 195191 Submitted by: Guy Yur <guyyur@gmail.com> (original version) MFC after: 1 week Changes: head/usr.sbin/rtadvd/if.c
A commit references this bug: Author: markj Date: Wed May 8 16:04:33 UTC 2019 New revision: 347349 URL: https://svnweb.freebsd.org/changeset/base/347349 Log: MFC r346960: Retry upon NET_RT_IFLIST sysctl failure. PR: 195191 Changes: _U stable/12/ stable/12/usr.sbin/rtadvd/if.c
A commit references this bug: Author: markj Date: Wed May 8 16:07:43 UTC 2019 New revision: 347353 URL: https://svnweb.freebsd.org/changeset/base/347353 Log: MFC r346960: Retry upon NET_RT_IFLIST sysctl failure. PR: 195191 Changes: _U stable/11/ stable/11/usr.sbin/rtadvd/if.c
Thanks for the report.