pfSense

That change has made the problem worse. I copied the new interfaces.inc to my Fri Mar 7 installation and rebooted. Then tested by dropping the LAN interface. If that's not a valid method, then my apologies.

Originally, only the LAN interface that experienced the link event lost it's IPv6 prefix.

Now, ALL IPv6 addressing is lost, on every interface.

--


Mar 10 13:35:48 dhcp6c[24147]: check_exit: exiting
Mar 10 13:35:48 php: rc.newwanipv6: rc.newwanipv6: Failed to update wan IPv6, restarting...
Mar 10 13:35:48 php: rc.newwanipv6: rc.newwanipv6: Informational is starting re1.
Mar 10 13:35:47 rtsold: Starting dhcp6 client for interface wan(re1)
Mar 10 13:35:47 dhcp6c[50852]: client6_init: skip opening control port
Mar 10 13:35:47 dhcp6c[50852]: client6_init: failed initialize control message authentication
Mar 10 13:35:47 dhcp6c[50852]: dhcp6_ctl_authinit: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Mar 10 13:35:47 dhcp6c[24147]: client6_recvreply: status code: success
Mar 10 13:35:47 php: rc.newwanipv6: rc.newwanipv6: Failed to update wan IPv6, restarting...
Mar 10 13:35:47 php: rc.newwanipv6: rc.newwanipv6: Informational is starting re1.
Mar 10 13:35:46 dhcp6c[24147]: client6_recvreply: status code: success
Mar 10 13:35:46 dhcp6c[24147]: ifaddrconf: failed to remove an address on re0: Can't assign requested address
Mar 10 13:35:45 php: rc.linkup: Accept router advertisements on interface re1
Mar 10 13:35:45 php: rc.linkup: HOTPLUG: Configuring interface lan
Mar 10 13:35:45 php: rc.linkup: DEVD Ethernet attached event for lan
Mar 10 13:35:43 kernel: re0: link state changed to UP
Mar 10 13:35:43 check_reload_status: Linkup starting re0
Mar 10 13:35:33 php: rc.linkup: DEVD Ethernet detached event for lan
Mar 10 13:35:31 kernel: re0: link state changed to DOWN

-- resolved --

The "just send a HUP to dhcp6 to get it to reload" change checked in today is a good fix.
https://redmine.pfsense.org/projects/pfsense/repository/revisions/e5b009b8e770b292d9f4b6fd01ed1400bde83ea4

I seem to be running into this bug in pfSense 2.1.3-RELEASE. It seems like a SIGHUP is properly being sent to the dhcp6c process but something happens in /etc/rc.newwanipv6 that causes the LAN IPv6 traffic to stop working.

I'm getting the same output that David was getting and one thing that stuck out to me was:

Jun  8 22:04:02 pfSense php: rc.newwanipv6: rc.newwanipv6: Failed to update WAN[wan] IPv6, restarting...

I dug into /etc/rc.newwanipv6 and found that simply commenting out the exit (around line 91) resolved the issue for me.

/*
 * NOTE: Take care of openvpn and similar if you generate the event to reconfigure an interface.
 *      i.e. OpenVPN might be in tap mode and not have an ip.
 */
if ((empty($curwanipv6) || !is_ipaddrv6($curwanipv6)) && substr($interface_real, 0, 4) != "ovpn") {
        log_error("rc.newwanipv6: Failed to update {$interface_descr}[{$interface}] IPv6, restarting...");
        // send_event("interface reconfigure {$interface}");
        //exit;
}

I'm not sure if this will introduce any other issues but I haven't noticed anything so far. A better solution would probably be to modify that if statement to detect if dhcp6c is being reloaded.

Derek Ivey wrote:

I seem to be running into this bug in pfSense 2.1.3-RELEASE. It seems like a SIGHUP is properly being sent to the dhcp6c process but something happens in /etc/rc.newwanipv6 that causes the LAN IPv6 traffic to stop working.

I'm getting the same output that David was getting and one thing that stuck out to me was:

[...]

I dug into /etc/rc.newwanipv6 and found that simply commenting out the exit (around line 91) resolved the issue for me.

[...]

I'm not sure if this will introduce any other issues but I haven't noticed anything so far. A better solution would probably be to modify that if statement to detect if dhcp6c is being reloaded.

Nevermind! I spoke too soon! Commenting out the exit caused me to lose my LAN IPv4 address somehow. I found a better solution though... sleeping for 3 seconds before that if statement seems to help, even though I still see that log entry... not sure why. For some reason sleeping only works in /etc/rc.newwanipv6. I tried sleeping right after the posix_kill call in /etc/inc/interfaces.inc instead but that didn't help.

Basically if I don't sleep, this is what it looks like when the link goes down and comes back up:

Reply from 2607:f8b0:4005:800::1001: time=15ms
Reply from 2607:f8b0:4005:800::1001: time=14ms
Reply from 2607:f8b0:4005:800::1001: time=14ms
--- link down/up ---
Request timed out.
Request timed out.
Request timed out.
--- SIGHUP on the dhcp6c process restores IPv6 temporarily ---
Reply from 2607:f8b0:4005:800::1001: time=15ms
Reply from 2607:f8b0:4005:800::1001: time=14ms
Reply from 2607:f8b0:4005:800::1001: time=14ms
Reply from 2607:f8b0:4005:800::1001: time=14ms
Reply from 2607:f8b0:4005:800::1001: time=14ms
--- IPv6 goes down again due to something in /etc/rc.newwannipv6 ---
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.