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

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.

doktornotor

Well, I get DHCPv6 traffic blocked even on LAN, without any bogonsv6 of course.


Jul  5 15:01:14 gw pf: 00:00:12.746276 rule 5/0(match): block in on vr0: (hlim 64, next-header UDP (17) payload length: 32) fe80::240:8cff:fe7a:7a5c.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=dcdc9d (client ID hwaddr type 1 00408c7a7a5c) (elapsed time 52080))
Jul  5 15:02:17 gw pf: 00:00:04.172277 rule 5/0(match): block in on vr0: (hlim 1, next-header UDP (17) payload length: 38) fe80::21b:78ff:fe0e:f84b.546 > ff02::1:2.547: [udp sum ok] dhcp6 inf-req (xid=23468c (elapsed time 0) (client ID hwaddr type 1 001b780ef84b) (option request status code))

https://redmine.pfsense.org/issues/3074

jimp

@doktornotor:

Well, I get DHCPv6 traffic blocked even on LAN, without any bogonsv6 of course.


Jul  5 15:01:14 gw pf: 00:00:12.746276 rule 5/0(match): block in on vr0: (hlim 64, next-header UDP (17) payload length: 32) fe80::240:8cff:fe7a:7a5c.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=dcdc9d (client ID hwaddr type 1 00408c7a7a5c) (elapsed time 52080))
Jul  5 15:02:17 gw pf: 00:00:04.172277 rule 5/0(match): block in on vr0: (hlim 1, next-header UDP (17) payload length: 38) fe80::21b:78ff:fe0e:f84b.546 > ff02::1:2.547: [udp sum ok] dhcp6 inf-req (xid=23468c (elapsed time 0) (client ID hwaddr type 1 001b780ef84b) (option request status code))

https://redmine.pfsense.org/issues/3074

Do you have a separate thread for that already? It doesn't quite belong in this one. Different issue entirely.

doktornotor

I have filed a separate issue… sorry. :-)

jimp

@doktornotor:

I have filed a separate issue… sorry. :-)

I saw it on there but I didn't know if there was a forum thread (I've been busy and not following close this week), it needs some discussion/troubleshooting on the forum and not back-and-forth on the ticket and I figured I'd try to help a bit, just not on the ticket since it's missing some info.

razzfazz

As mentioned in the other thread, I see the same issue of DHCP6 traffic not being allowed in when using "track interface" (i.e., no DHCP relay involved); see issue 3028.

razzfazz

I believe the issue that I'm seeing with track interface is due to what looks like a typo in /etc/inc/filter.inc:870:


                        $oc['track6-interface'] = $oc['track6-interface'];

Looking at the surrounding code, it seems like the intended destination was $oic, not $oc. The typo causes the 'track6-interface' not to be added to FilterIfList, which in turn causes the pass rules to not be generated.

razzfazz

Confirmed on my local box that changing the destination of the assignment to $oic causes the appropriate rules to be generated on the tracking interface. Pull request.

shavenne

radvd seems now to be stable for me too. But my Ubuntu clients don't get a address until I start dhclient -6 once?! The only address it sets is the fe80-address (SLAAC?)
I have 'iface eth0 inet6 auto' in the /etc/network/interfaces. Shouldn't they get a address automatically without starting a DHCP client??