Losing ipv6 address on network blip, radvd needs restart

Started by rocketraman, August 14, 2023, 09:09:18 PM

Previous topic - Next topic
My router uses "Track Interface" for LAN IPv6 Configuration Type, Manual Configuration checked. DHCPv6 is disabled, and Router Advertisements are "Unmanaged".

I had a network blip of a few seconds and when the network came back up, the router did have a WAN IPv6 address assigned but my LAN clients lost their ipv6 addresses. Restarting the radvd service manually restored IPv6 to LAN clients.

Looking at the logs I see these radv and network related logs when the network goes down:

Aug 12 01:37:27 router.home.arpa radvd[44978]: exiting, 1 sigterm(s) received
Aug 12 01:37:27 router.home.arpa radvd[44978]: sending stop adverts
Aug 12 01:37:27 router.home.arpa radvd[44978]: removing /var/run/radvd.pid
Aug 12 01:37:27 router.home.arpa radvd[44978]: returning from radvd main
Aug 12 01:37:28 router.home.arpa dhcp6c[57660]: transmit failed: Network is down
Aug 12 01:37:29 router.home.arpa dhcp6c[57660]: transmit failed: Network is down
Aug 12 01:37:31 router.home.arpa dhcp6c[57660]: transmit failed: Network is down


and then these logs whe the network comes back up a few seconds later:

Aug 12 01:37:35 router.home.arpa opnsense[99737]: /usr/local/etc/rc.linkup: DEVD: Ethernet attached event for wan(igb0)
Aug 12 01:37:35 router.home.arpa dhcp6c[15717]: RTSOLD script - Sending SIGHUP to dhcp6c
Aug 12 01:37:35 router.home.arpa opnsense[...]: [...snip bunch of etc/rc.linkup etc/rc.newwanip stuff...]
Aug 12 01:37:36 router.home.arpa opnsense[99737]: /usr/local/etc/rc.linkup: dhcpd_radvd_configure(manual) found no suitable IPv6 address on igb3
Aug 12 01:37:36 router.home.arpa radvd[33395]: version 2.19 started
Aug 12 01:37:36 router.home.arpa dhcp6c[40844]: RTSOLD script - Sending SIGHUP to dhcp6c
Aug 12 01:37:38 router.home.arpa dhcp6c[71649]: dhcp6c_script: REQUEST on igb0 executing
Aug 12 01:37:38 router.home.arpa dhcp6c[73996]: dhcp6c_script: REQUEST on igb0 renewal
Aug 12 01:37:38 router.home.arpa opnsense[74889]: /usr/local/etc/rc.newwanipv6: Failed to detect IP for WAN[wan]
Aug 12 01:37:35 router.home.arpa opnsense[...]: [...snip bunch of etc/rc.linkup etc/rc.newwanip stuff...]


and then when I fixed things by restarting the radvd service:

Aug 12 13:37:17 router.home.arpa dhcp6c[94122]: dhcp6c_script: RENEW on igb0 executing
Aug 12 13:37:17 router.home.arpa dhcp6c[96448]: dhcp6c_script: RENEW on igb0 executing
Aug 12 13:37:17 router.home.arpa opnsense[95010]: /usr/local/etc/rc.newwanipv6: No IP change detected (current: 2001:1970:4000:a2::xxxx, interface: WAN[wan])
Aug 12 13:37:17 router.home.arpa opnsense[177]: /usr/local/etc/rc.newwanipv6: No IP change detected (current: 2001:1970:4000:a2::xxxx, interface: WAN[wan])


I note there are no messages from `etc/rc.newwanipv6` in between the message "Failed to detect IP for WAN[wan] at Aug 12 01:37:38 and the message at Aug 12 13:37:17 "No IP change detected (current: 2001:1970:4000:a2::xxxx, interface: WAN[wan])". This makes me think there is some kind of timing issue or missing event when the WAN ipv6 address is assigned.

That is a well-known problem that was adressed by 23.7.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 770 up, Bufferbloat A

Quote from: meyergru on August 15, 2023, 12:09:30 AM
That is a well-known problem that was adressed by 23.7.

Oh, thank you. I searched in the release notes for radvd but didn't find anything. I guess this item is probably the relevant one:

Quoteinterfaces: on forceful IPv6 reload do not lose the event handling

Yes that's the follow up change. The main change was:

o interfaces: introduce a lock and DAD timer into newwanip for IPv6


Cheers,
Franco