IPv6 DHCP-PD – radvd dies after interface reset - dhcpv6 does not reaquire addr

darkcrucible

I'm not sure if what I'm seeing after upgrading to the March 30th snapshot is the same issue for this thread but I don't have any IPv6 connectivity at all on the LAN. RADVD is sending advertisements, all LAN clients pick up an address (but not DNS) but there is no connectivity.

I can't ping the router's LAN address

I get a lot of failed to update WAN IPv6 address errors.

Mar 31 17:18:05 	php: : ROUTING: setting IPv6 default route to fe80::201:5cff:fe31:b7c1%vr1
Mar 31 10:18:08 	php: : rc.newwanipv6: Failed to update wan IPv6, restarting...
Mar 31 17:18:11 	check_reload_status: Updating all dyndns
Mar 31 10:18:18 	php: : rc.newwanip: Informational is starting vr1.
Mar 31 10:18:18 	php: : rc.newwanip: on (IP address: 24.x.y.z) (interface: wan) (real interface: vr1).
Mar 31 10:18:18 	php: : Accept router advertisements on interface vr1
Mar 31 17:18:18 	check_reload_status: Restarting ipsec tunnels
Mar 31 10:18:18 	php: : ROUTING: setting default route to 24.x.yyy.1
Mar 31 10:18:18 	php: : ROUTING: setting IPv6 default route to fe80::201:5cff:fe31:b7c1%vr1
Mar 31 17:18:20 	check_reload_status: Reloading filter
Mar 31 10:18:21 	dhcp6c[18942]: client6_recvreply: status code: success
Mar 31 10:18:21 	dhcp6c[48004]: dhcp6_ctl_authinit: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Mar 31 10:18:22 	dhcp6c[48004]: client6_init: failed initialize control message authentication
Mar 31 10:18:22 	dhcp6c[48004]: client6_init: skip opening control port
Mar 31 10:18:23 	php: : rc.newwanipv6: Informational is starting vr1.
Mar 31 10:18:25 	php: : Resyncing OpenVPN instances for interface WAN.
Mar 31 10:18:26 	php: : Creating rrd update script
Mar 31 10:18:28 	php: : rc.newwanipv6: Failed to update wan IPv6, restarting...
Mar 31 10:18:28 	dhcp6c[18942]: client6_recvadvert: XID mismatch
Mar 31 10:18:28 	dhcp6c[18942]: client6_recvadvert: XID mismatch
Mar 31 10:18:28 	dhcp6c[18942]: client6_recvadvert: XID mismatch
Mar 31 10:18:28 	dhcp6c[18942]: client6_recvadvert: XID mismatch
Mar 31 10:18:28 	dhcp6c[18942]: client6_recvadvert: XID mismatch
Mar 31 10:18:28 	dhcp6c[18942]: client6_recvadvert: XID mismatch
Mar 31 10:18:28 	dhcp6c[18942]: client6_recvreply: status code: success
Mar 31 10:18:30 	php: : rc.newwanipv6: Informational is starting vr1.
Mar 31 10:18:30 	php: : pfSense package system has detected an ip change 0.0.0.0 -> 24.x.y.z ... Restarting packages.
Mar 31 17:18:30 	check_reload_status: Starting packages
Mar 31 10:18:35 	php: : rc.newwanipv6: Failed to update wan IPv6, restarting...
Mar 31 10:18:35 	dhcp6c[18942]: check_exit: exiting
Mar 31 10:18:40 	php: : Restarting/Starting all packages.
Mar 31 10:18:40 	php: : The OpenVPN Client Export Utility package is missing its configuration file and must be reinstalled.
Mar 31 10:18:44 	php: : rc.newwanipv6: Informational is starting vr1.
Mar 31 17:18:46 	check_reload_status: Syncing firewall
Mar 31 10:18:49 	php: : rc.newwanipv6: Failed to update wan IPv6, restarting...
Mar 31 17:18:54 	php: : Creating rrd update script
Mar 31 17:19:38 	php: : PBI dir for zip-3.0-i386 was not found - cannot cleanup PBI files
Mar 31 17:19:38 	php: : PBI dir for p7zip-9.20.1-i386 was not found - cannot cleanup PBI files
Mar 31 17:19:40 	check_reload_status: Syncing firewall
Mar 31 17:19:43 	php: : Beginning package installation for OpenVPN Client Export Utility .
Mar 31 17:21:48 	check_reload_status: Syncing firewall
Mar 31 10:21:49 	syslogd: exiting on signal 15
Mar 31 10:21:49 	syslogd: kernel boot file is /boot/kernel/kernel
Mar 31 10:21:51 	php: : Restarting/Starting all packages.

priller

darkcrucible: Are you on a cable modem?

When I have seen the "dhcp6c[18942]: client6_recvadvert: XID mismatch", pfsense will just keep thrashing until I power cycle the cable modem and reboot pfsense. Then it clears and will obtain the IPv6 addressing (IPv4 is always fine).

This seems to happen after updating to a newer snapshot.

priller

Bit of update. Once again at renewal time, all IPv6 addressing was lost. The only syslog message was:

Apr 1 13:32:49 dhcp6c[29310]: client6_timo: all information to be updated was canceled

During this time, I was also running a packet capture on the WAN.

It was interesting to see that pfSense was getting two replies from Comcast, different server ID's. One had the addresses that should have been renewed, the other had different addressing. So, I suspect the pfSense didn't like that and killed everything.

So, I have a contact within Comcast and will see what they have to say about the two different responses. And what the expected client response should have been.

Also, after a reboot, I'm back to having to manually start RADVD.

johnpoz

I have been having issues with my comcast ipv6 as well - have not gotten around to looking into it yet, not something that I really need.. Just like having up to play with when I want to play with ipv6.

But I am seeing

Mar 31 11:44:38 radvd[55232]: Exiting, failed to read config file.
Mar 31 11:44:38 radvd[55232]: error parsing or activating the config file: /var/etc/radvd.conf
Mar 31 11:44:38 radvd[55232]: syntax error in /var/etc/radvd.conf, line 2:
Mar 31 11:44:38 radvd[55232]: version 1.9.1 started

You look in the conf and there is nothing there.

cat /var/etc/radvd.conf

Automatically Generated, do not edit

Currently running
2.1-BETA1 (i386)
built on Fri Mar 22 11:05:31 EDT 2013
FreeBSD 8.3-RELEASE-p6

I will update when I get home and look into it a bit deeper. I was working fine for long time, then just noticed a while back not working after update to snap.. I to was going to do a clean install, just have not go around to that either..

If I do a sniff I do see this which seems odd - seems like offering 2 prefixes?

2prefix.jpg_thumb

priller

I have opened the following bug: https://redmine.pfsense.org/issues/2919

I was running a packet capture when the lease expired. The IPv6 DHCP server is responding properly, but pfSense never binds.

darkcrucible

With the April 8th snapshot, IPv6 connectivity with my Comcast link is restored to the LAN clients. I skimmed through redmine to see what might be affecting this. A few items stood out. Not sure exactly which one.

Getting connectivity back is certainly an improvement. pfsense itself still doesn't use the IPv6 DNS given to it by Comcast and none of the LAN clients seem to use the IPv6 LAN address of pfsense for DNS forwarding like they used to back in February.

I'll report back in a few days after the renewal on whether connectivity remains and if the pfsense starts using IPv6 DNS at that point.

johnpoz

sweet!!!! I will try this build when I get home!

Michael Sh.

On my routers DHCP v6 not working at all after switching on rtsol.

rtsold should be used on IPv6 hosts (non-router nodes) only.

[2.1-BETA1][root@router.lan]/root(105): /usr/sbin/rtsold -1 -p /var/run/rtsold_em0.pid -O /var/etc/rtsold_em0_script.sh em0
rtsold: kernel is configured as a router, not a host

johnpoz

Still not working

2.1-BETA1 (i386)
built on Tue Apr 9 13:23:01 EDT 2013

Get errors that radvd.conf is bad

Apr 10 08:09:51 radvd[74841]: Exiting, failed to read config file.
Apr 10 08:09:51 radvd[74841]: error parsing or activating the config file: /var/etc/radvd.conf
Apr 10 08:09:51 radvd[74841]: syntax error in /var/etc/radvd.conf, line 2:

There is nothing in this file other than

[2.1-BETA1][root@pfsense.local.lan]/var/etc(11): cat /var/etc/radvd.conf

Automatically Generated, do not edit

[2.1-BETA1][root@pfsense.local.lan]/var/etc(12):

What is suppose to update this file? I tried clean install, and I did see my 2001 address on wan and 2006 address on lan, but it ended it :2 – and after reboot gone? No nothing on wan other than local link address, and nothing on lan.

This was working perfect, and then just stopped??

johnpoz

So I gave it some time, and now getting /128 on wan and /64 on lan

WAN (wan) -> em1 -> v4/DHCP4: 24.13.xx.xx/21
v6/DHCP6: 2001:558:xxxx:12c:405d:37e1:34e1:fe29/128
LAN (lan) -> em0 -> v4: 192.168.1.253/24
v6/t6: 2601:d:xxxx:d7:250:56ff:fe00:2/64

So it is working - but here is question. I don't want the lan IP to use the mac, which clearly is where that address is coming from. What would be nicer is if the lan interface grabbed the first IP in the net

2601:d:xxxx:d7::1

so my mac on the lan interface is

em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=98 <vlan_mtu,vlan_hwtagging,vlan_hwcsum>ether 00:50:56:00:00:02

Is there some setting that needs to be made so it doesn't do that, and just uses the first IP in the network its assigned?</vlan_mtu,vlan_hwtagging,vlan_hwcsum></up,broadcast,running,simplex,multicast>

darkcrucible

At 48 hours, the renewal time, the IPv6 LAN address disappears, RADVD vanishes from the services page, and resolv.conf picks up the IPv6 DNS from Comast (it only had the 75.75.x addresses prior to the renewal).

address.png_thumb

dns.png_thumb

service.png_thumb

priller

@darkcrucible:

At 48 hours, the renewal time, the IPv6 LAN address disappears, RADVD vanishes from the services page, and resolv.conf picks up the IPv6 DNS from Comast (it only had the 75.75.x addresses prior to the renewal).

pfSense will only bind the LAN IPv6 prefix at boot time. Once the lease expires it will never rebind. It just keeps trying to infinity. I'd say this is definitely a Show-Stopper bug.

rebind.jpg_thumb

johnpoz

Yup seems I lost my IPs as well…

So I have updated to

2.1-BETA1 (i386)
built on Fri Apr 12 04:55:08 EDT 2013
FreeBSD 8.3-RELEASE-p7

Still not working, so turned off ipv6 on the wan - then back on. Got my 2001 on my wan, then a bit later new 2601 on my lan - but different subnet. Gawd that sucks - if the /64 handed to me is going to change every time, I will just go back to the tunnel from HE. This never changed.

Also noticed that delete virtual IPs is still not working as well. Since the virtual I put on my lan with ::1 as the address vs the mac containing ipv6 it get would not delete. Using IE gives a warning about deleting, you say yes never deletes - firefox no such warning, but might because I popups blocked. But does not delete. So once got new address on lan, I change my virtual to be in that /64 and now I have ipv6 access again. But its a pain, lets see if goes away in 48 hours.

And I looked in the config - only place that address was listed was


	 <virtualip><vip><mode>ipalias</mode>
			<interface>lan</interface>
			 <descr><type>single</type>
			<subnet_bits>64</subnet_bits>
			<subnet>2601:d:xxxx:d7::1</subnet></descr></vip></virtualip>

priller

@johnpoz:

Still not working, so turned off ipv6 on the wan - then back on. Got my 2001 on my wan, then a bit later new 2601 on my lan - but different subnet. Gawd that sucks - if the /64 handed to me is going to change every time, I will just go back to the tunnel from HE. This never changed.

That's what I've ended up doing. HE is solid.

After studying my packet captures, I see two related issues here.

When it's time to renew, pfs sends a REBIND. The response from the server is a renewal of the same prefix. That's good, unfortunately that is not processed by pfs … that's bad. The result is that the LAN IPv6 address is purged and never returns.
When pfs does an initial SOLICIT. You get a response from two Comcast DHCP servers, each with a different prefix. One is the what you had before (as long as you are within the lease window) the other is a new one. If pfs remembered it's last prefix, it should just rebind on a matching response. However, it does not. The end result is that your LAN prefix can keep changing each time you reset/reboot. Again, that is in the bad category.

shavenne

Any fix available yet? ???
My ISP (Deutsche Telekom) gives me an IPv6 address (dual stack) since I switched to IPTV. It comes via DHCP6, but it's not static (it changes everytime I reboot or go offline+online).
LAN is set to Track Interface.
When I reboot, WAN is getting the IPv6 IP, LAN is also getting another IPv6 IP, but radvd doesn't seem to work. When I go to Services and restart radvd my clients are also getting IPv6 IPs and it works perfect. But after about 10 or 20 minutes radvd kills itself and disappeares in the Services menu and the LAN interface doesn't have it's IPv6 address anymore.

Apr 25 19:18:10 radvd[58188]: version 1.9.1 started
Apr 25 19:18:41 radvd[58287]: attempting to reread config file
Apr 25 19:18:41 radvd[58287]: resuming normal operation
Apr 25 19:29:22 radvd[58287]: sendmsg: Can't assign requested address
Apr 25 19:29:23 radvd[58287]: attempting to reread config file
Apr 25 19:29:23 radvd[58287]: syntax error in /var/etc/radvd.conf, line 44:
Apr 25 19:29:23 radvd[58287]: error parsing or activating the config file: /var/etc/radvd.conf
Apr 25 19:44:31 radvd[30802]: version 1.9.1 started
Apr 25 19:44:31 radvd[30802]: syntax error in /var/etc/radvd.conf, line 2:
Apr 25 19:44:31 radvd[30802]: error parsing or activating the config file: /var/etc/radvd.conf
Apr 25 19:44:31 radvd[30802]: Exiting, failed to read config file.

Any suggestions? :-[
It's unusable for me at the moment.

mokuso

The reason the /64 allocation changes is that the /var/db/dhcp6c_duid file does not persist on reboot. Each reboot this file is recreated and a new DUID is assigned.

It would be nice to have the option to retain this file.

MaxPF

Any updates on this one?

johnpoz

I still don't see it working.. Im on

2.1-BETA1 (i386)
built on Tue May 21 20:50:09 EDT 2013
FreeBSD 8.3-RELEASE-p8

And when I updated to it the other day I tried to get it working again.. It look like it took it for a second, I saw an IPv6 in inf status, then next thing it was gone.

Now I know they just added the RC tag - so I might update tonight again, but something is still not right with this.

priller

Here's the bug for the IPv6 addressing being lost: http://redmine.pfsense.org/issues/2919

I would definitely consider this a Show Stopper bug. The ability to acquire and maintain addressing is a basic function, without that nothing else matters. I was surprised to see the change to RC status, with issues like this remaining.

MaxPF

@priller:

Here's the bug for the IPv6 addressing being lost: http://redmine.pfsense.org/issues/2919

I would definitely consider this a Show Stopper bug. The ability to acquire and maintain addressing is a basic function, without that nothing else matters. I was surprised to see the change to RC status, with issues like this remaining.

That was exactly what I thought. When I read about the RC status I went back looking for this hoping that I missed the update. Considering that the main feature of 2.1 is IPV6 support, this is pretty major, together with the broken 6RD support.