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

[johnpoz]

Like I said before, lets see how it works when 2.1 is released - its currently so unstable that its not viable for anyone wanting to actually use ipv6 even for testing.. Since you may or may not be even to pull a address, let alone maintain one for any length of time.

That being said, my HE tunnel has been rock solid since I went back to it ;)  Even upgraded snaps a couple of times - and upon reboot there is is solid..  Now its got a bit more latency then native - but hey it works!! ;)

I am just going to wait til 2.1 is released, will then do a clean install and see if it works.

[razzfazz]

@priller:

May not be the root cause, but it should be noted that the only time they appear is when pfSense is not pulling IPv6 addressing.  That is the only 'error' in the logs.

Hm, I guess I do wonder if these may somehow be related to a second instance of the DHCP6 client being started…

[razzfazz]

@johnpoz:

Like I said before, lets see how it works when 2.1 is released - its currently so unstable that its not viable for anyone wanting to actually use ipv6 even for testing..

I think that's a bit of an over-generalization. It's been working fine for me on Comcast Home for the past several snapshots now, so it certainly looks like the problem isn't universal.

[jimp]

I encourage people to not stop trying, too. If you wait for a release, and it works for everyone except you and nobody else can reproduce a problem, then it would never get fixed properly.

[reslip]

I've sense switched off ipv6 on the lan side as I was having too many issues with clients and radvd. It was as though the wan interface was never properly brought up so ipv6 was not routing properly. Now for ipv6 on the WAN I am showing some errors acquiring an address. From system.log…

Jun 29 03:34:42 fw dhcp6c[23649]: dhcp6_ctl_authinit: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Jun 29 03:34:42 fw dhcp6c[23649]: client6_init: failed initialize control message authentication
Jun 29 03:34:42 fw dhcp6c[23649]: client6_init: skip opening control port
Jun 29 03:34:42 fw dhcp6c[23649]: cfparse: cfparse: fopen(/var/etc/dhcp6c_wan.conf): No such file or directory
….
Jun 29 03:34:43 fw php: : The command '/sbin/dhclient -c /var/etc/dhclient_wan.conf fxp1 > /tmp/fxp1_output 2> /tmp/fxp1_error_output' returned exit code '1', the output was ''
Jun 29 03:34:43 fw php: : Accept router advertisements on interface fxp1
Jun 29 03:34:44 fw php: : rc.newwanip: Informational is starting fxp1.
Jun 29 03:34:44 fw php: : rc.newwanip: on (IP address: ) (interface: wan) (real interface: fxp1).
Jun 29 03:34:44 fw php: : rc.newwanip: Failed to update wan IP, restarting...
....
[2.1-RC0][admin@fw.xxxx.com]/var/etc(29): cat dhclient_wan.conf
interface "fxp1" {
timeout 60;
retry 15;
select-timeout 0;
initial-interval 1;

script "/sbin/dhclient-script";
}

[2.1-RC0][admin@fw.xxxx.com]/var/etc(30): cat dhcp6c_wan.conf
interface fxp1 {
        send ia-na 0;  # request stateful address
send ia-na 0; # request stateful address
send ia-pd 0; # request prefix delegation
request domain-name-servers;
request domain-name;
script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc na 0 { };
id-assoc pd 0 {
};

[eri--]

I just pushed some fixes related to this.
Can you please either gitsync or try with tomorrow snapshots.

[reslip]

From the developer shell I did playback gitsync RELENG_2_1. I am still getting errors for dhcp6 on the WAN side.

Jul 3 10:58:55 php: rc.bootup: ROUTING: setting IPv6 default route to fe80::201:5cff:xxxx:xxxx%fxp1
Jul 3 10:58:55 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Jul 3 10:58:55 dhcp6c[42896]: dhcp6_ctl_authinit: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Jul 3 10:58:55 dhcp6c[42896]: client6_init: failed initialize control message authentication
Jul 3 10:58:55 dhcp6c[42896]: client6_init: skip opening control port
Jul 3 10:58:55 dhcp6c[42896]: add_options: /var/etc/dhcp6c_wan.conf:3 IA_NA (0) is not defined
Jul 3 10:58:55 dhcp6c[42896]: main: failed to parse configuration file

[eri--]

You seem to have other issues than dhcp.
Can you share your config(/var/etc/dhcp6c_wan.conf))?

[reslip]

[2.1-RC0][admin@fw.subnothing.com]/var/etc(8): cat dhcp6c_wan.conf
interface fxp1 {
        send ia-na 0;   # request stateful address
 	send ia-na 0;	# request stateful address
	send ia-pd 0;	# request prefix delegation
	request domain-name-servers;
	request domain-name;
	script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please
};
id-assoc na 0 { };
id-assoc pd 0 {
};

[qubit]

@reslip:

From the developer shell I did playback gitsync RELENG_2_1. I am still getting errors for dhcp6 on the WAN side.

Jul 3 10:58:55 php: rc.bootup: ROUTING: setting IPv6 default route to fe80::201:5cff:xxxx:xxxx%fxp1
Jul 3 10:58:55 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Jul 3 10:58:55 dhcp6c[42896]: dhcp6_ctl_authinit: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Jul 3 10:58:55 dhcp6c[42896]: client6_init: failed initialize control message authentication
Jul 3 10:58:55 dhcp6c[42896]: client6_init: skip opening control port
Jul 3 10:58:55 dhcp6c[42896]: add_options: /var/etc/dhcp6c_wan.conf:3 IA_NA (0) is not defined
Jul 3 10:58:55 dhcp6c[42896]: main: failed to parse configuration file

As of this post I think the three commits relating to rc.newwanip are in master and not RELENG_2_1 yet

[razzfazz]

IPv6 (Comcast) had been working fine for me for the past several snapshots, but with today's build, I get no IPv6 address on either the WAN or the LAN interface. I, too, see the following entry in my system log:

dhcp6c[59733]: add_options: /var/etc/dhcp6c_wan.conf:3 IA_NA (0) is not defined

Looking at /var/etc/dhcp6c_wan.conf, it looks like the issue might be that there are two identical IA-NA lines:

        send ia-na 0;   # request stateful address
 	send ia-na 0;	# request stateful address

Is that what the upcoming fixes are for?

[razzfazz]

Replying to myself, removing the duplicate line does appear to restore IPv6 addressing for me.

[eri--]

I pushed all the fixes in 2.1 and also fixed this issue of double line in dhcp6c config.
Please test.

[BrianPlencner]

@ermal:

I pushed all the fixes in 2.1 and also fixed this issue of double line in dhcp6c config.
Please test.

So that we are all on the same page, I was going to download and test the build that you are talking about.

From this page:  http://snapshots.pfsense.org/FreeBSD_RELENG_8_3/i386/pfSense_RELENG_2_1/livecd_installer/?C=M;O=D

I am looking at this item
Filename: pfSense-LiveCD-2.1-RC0-i386-20130704-0301.iso.gz
Last modified: 04-Jul-2013 03:37
Size: 80M

Is this the one that includes all the fixes that you speak of?  If so, I'll download that one today and test it out as well.

Thanks,

–Brian

[eri--]

The php fixes i do not think so.
You probably have to wait for the next snapshot.

[BrianPlencner]

Thanks for the quick reply.  I can wait for the next snapshot.

–Brian

[razzfazz]

Yeah, that looks much better.

[qubit]

Upgraded to today's snapshot (July 4) and everything seems to be working here on Comcast again. Upon boot I get ipv6 addressing. Pulling out the cable to the WAN and plugging it back gets ipv6 back cleanly and radvd restarts as well. Sometimes NTP crashes when getting Internet but starting the service a single time brings it up. I no longer get any XID mismatches and now only one dhcp6 is running. Manually releasing and renewing the WAN in Status-> Interfaces only brings up ipv4, but going to Interface->WAN and clicking save and apply only once brings it up perfectly.

The only thing that killed ipv6 was updating the bogonsv6 table. I noticed that a bunch of ipv6 multicast activity was being blocked in the firewall log after updating the bogon rules. A lot of traffic from Comcast's ipv6 gateway on the WAN (fe80 address) was being blocked by```
drop from <bogonsv6> to any</bogonsv6>

I actually haven't gotten this far before so hopefully things will survive past 2 and 4 days. Thanks for the hard work.

[priller]

@qubit:

The only thing that killed ipv6 was updating the bogonsv6 table. I noticed that a bunch of ipv6 multicast activity was being blocked in the firewall log after updating the bogon rules. A lot of traffic from Comcast's ipv6 gateway on the WAN (fe80 address) was being blocked by```
drop from <bogonsv6> to any</bogonsv6>

Excellent observation. I was starting to suspect that.

That would certainly explain why a fresh install comes up just fine after the running one pukes on IPv6.

[jimp]

It should have logged the blocked traffic, did you see anything in the firewall logs at the time?

If we can locate the conflicting addresses we can filter them out during the bogon update routine if we have to.