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

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??

jimp

@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??

Probably best to put that in another thread, but my Ubuntu laptop pulls a V6 IP from DHCP without any intervention.

fe80 is link-local, you'll always have one of those when IPv6 is enabled, even if you don't have a connection to an IPv6 network. I use the network manager though, and IPv6 there is just set to "automatic"

$ sudo cat /etc/NetworkManager/system-connections/MYSSID
[connection]
id=MYSSID
uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
type=802-11-wireless
timestamp=1370526571

[802-11-wireless]
ssid=MYSSID
mode=infrastructure
mac-address=00:xx:xx:xx:xx:xx
seen-bssids=xx:xx:xx:xx:xx:xx;zz:zz:zz:zz:zz:zz;
security=802-11-wireless-security

[802-11-wireless-security]
key-mgmt=wpa-psk
psk=blah

[ipv4]
method=auto

[ipv6]
method=auto

saltspork

I've done a clean install of 2.1 and IPv6 now works, but dhcp6c reports an error and a filter reload is constantly triggered. Killing dhcp6c fixes the issue but takes down radvd with it.


Jul 9 14:40:57	dhcp6c[25113]: update_ia: status code for NA-0: no addresses
Jul 9 14:40:58	php: rc.newwanipv6: ROUTING: setting default route to [ISP v4 gateway IP]
Jul 9 14:40:51	check_reload_status: Reloading filter