IPv6 DHCP-PD – radvd dies after interface reset - dhcpv6 does not reaquire addr
-
The php fixes i do not think so.
You probably have to wait for the next snapshot. -
Thanks for the quick reply. I can wait for the next snapshot.
–Brian
-
Yeah, that looks much better.
-
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. -
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.
-
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.
-
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
-
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.
-
I have filed a separate issue… sorry. :-)
-
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.
-
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.
-
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.
-
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.
-
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?? -
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 -
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 -
Yesterday I did a clean install of the following version
Version 2.1-RC0 (i386)
built on Mon Jul 8 21:26:14 EDT 2013
FreeBSD 8.3-RELEASE-p8So far (uptime is 17 hours) things appear to be working. Here are a few items that I have noticed so far
• pfSense shows that my WAN IPv6 IP is 2001:558:6033:ad:….
As far as I know, this is a valid DHCPv6 IP from Comcast.• IPv6 Test sites (example www.test-ipv6.com) return a 10/10 result
• IPv6 only sites (example ipv6.speedtest.comcast.net) load without issue
• Comcast's IPv6 Information Center site (www.comcast6.net) loads and shows the following information
Your IP address is 2601:d:4c00:ca:1118:.......
Congrats! You are using IPv6 on the Comcast Cable network.• The Service "radvd" is running on pfSense
The big question in my mind is what will happen once the lease is up on the IPv6 IP, and it goes to renew it? That was the problem before, and from what it sounds like, that issue has been corrected. I'll report back in a few days with how things go.
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.
Could you provide a bit more information on how I can check my system to see if I am getting a similar error?
Thanks,
–Brian
-
I am also not seeing any immediate issues with the July 8th build. Good job to everyone that helped to fix this!
-
I upgraded to the built of Fri Jul 5 18:13:39 EDT 2013 and it's now been running for over 4 days and renewed without problems. This is the first time it renewed and maintained IPv6 connectivity. All the tests and comcast6.net are working. Previous as others report it would not work after the 4 days.
What ever changes has been made there going in the right direction.
I'll give it another day or two then update to the latest snapshot and see what happens and post my results.
Thanks for your dedicated work it's appreciated.
-
Could you provide a bit more information on how I can check my system to see if I am getting a similar error?
The main symptom is 100% CPU usage on one core while the filter reloads indefinitely.
