Please Help with DHCP6C on native /56
-
Hi, I really hope someone could help me a bit, I've been banging my head on a wall for the past 24 hours trying to get native ipv6 working.
I Sort of managed to get it working but it doesn't work automatically.
whats happening is I set up WAN for DHCP6 and prefix delegation, it created the proper config file for dhcp6c.and I set lan to track wan connection with 0 id.
nothing happens.
then I notice that dhcp6c never starts ever. so I start it manually with /usr/local/sbin/dhcp6c -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_em0.pid em0
once I type that everything magically works. .
I reboot, and same thing dhcp6c never runs … unless I type it in manually...
can someone please point me in the right direction as to why its not automatically starting?Thanks.
-
DHCP-PD will only work if you have at least one Track Interface network, or you configure DHCP-PD using the Advanced settings. See https://redmine.pfsense.org/issues/4544 for some commentary.
-
thanks, but I do have 1 track interface, its the lan interface, the ipv6 of the LAN is set to track interface wan with id0
-
@alphaz,
What do you mean by "created the proper config file for dhcp6c. "?
You shouldn't need to be creating any of this by hand. -
Hi awebster, thanks for your reply, what I mean is I clicked the right checkboxes and options, then saved in the gui, then went into the console and verified the file is as it should be with the correct settings, so the settings file is correct, because when I launch dhcp6c manually specifying the config file that it created from earlier it runs with no issues at all and everything just works. from all the people I've talked to, everyones dhcp6c seems to start itself.. mine just doesn't start automatically I was on 2.2.4 yesterday when I started trying to get this to work, and wasn't working then middle of the night 2.2.5 came out so I updated to that and still no change. still won't start by itself.
-
What are the settings on:
Interfaces -> WAN -> DHCP6 client configuration section (all checkboxes)
Interfaces -> LAN -> Track IPv6 Interface sectionLastly, the WAN IP you end up getting, is it inside the /56 or some other subnet ?
-
Hi awebster,
wan is dhcp6
with Only request an IPv6 prefix, do not request an IPv6 address checked
delegation size of /56
and send ip6 prefix hint checked.the LAN side is set to Track Interface WAN, and prefix id of 0
The WAN IP is blank, as I checked the do not request ipv6 address for wan thing..
as that's what everyone is telling me is supposed to happen with my provider? I tried unchecking it and it doesn't get anything either..
because the dhcp6c client simply doesn't execute automatically without me manually typing in shell command to start it.Thanks
-
Hi Alphaz,
Does your WAN connection happen to be IPoE and not PPPoE?
We've encountered a similar problem. pfsense is waiting on the ISP's BNG to send an RA before it'll trigger the dhcp6client, however the ISP's BNG is waiting on the router to send a DHCPv6 SOLICIT before it authenticates the customer and allows the router on to the network. Hence, a stalemate.I've raised a bug in redmine with basically exactly the above in the ticket:
https://redmine.pfsense.org/issues/5993 -
I went through same issues like alphaz yesterday with my provider. I'm on bonded DSL line and was pulling my hair after configuring and re-configuring same things over and over again. Everything looked correct (with exact same settings like alphaz), and I would still not get IPv6 address assigned to my LAN. Then occurred to me to check if dhcp6c is running, and, of course, it was not. The moment I started it manually I got IPv6 address.
Problem is, after every change, and on every reboot I would have to restart it myself. So, what piece of pfSense is supposed to take care of that?
-
Evaluate this: https://forum.pfsense.org/index.php?topic=101967.msg601280#msg601280
-
@hda:
https://forum.pfsense.org/index.php?topic=101967.msg601280#msg601280
That doesn't fix the problem I described above.
Problem is, after every change, and on every reboot I would have to restart it myself. So, what piece of pfSense is supposed to take care of that?
Try this patch to /etc/inc/interfaces.inc https://drive.google.com/open?id=0B4TgGdFbcHgZQmcyZVJUb3NPU0U
It just calls dhcp6c prior to rtsold. The overall rtsold/dhcp6c logic could do with a bit of a rethink.
-
@det:
Problem is, after every change, and on every reboot I would have to restart it myself. So, what piece of pfSense is supposed to take care of that?
Try this patch to /etc/inc/interfaces.inc https://drive.google.com/open?id=0B4TgGdFbcHgZQmcyZVJUb3NPU0U
It just calls dhcp6c prior to rtsold. The overall rtsold/dhcp6c logic could do with a bit of a rethink.
Is that patch for pfSense v2.2.6? It wants to modify the following code…
function interface_group_add_member($interface, $groupname) { $interface = get_real_interface($interface); if (does_interface_exist($interface)) mwexec("/sbin/ifconfig {$interface} group " . escapeshellarg($groupname), true); }…right before if statement. Is that correct?
-
Is that patch for pfSense v2.2.6? It wants to modify the following code…
Ahh sorry no, I was basing this on the daily snapshots.
The patch needs to be inserted above the mwexec() for rtsold around here: https://github.com/pfsense/pfsense/blob/master/src/etc/inc/interfaces.inc#L4010However it's probably best inserted after the enabling of accept_rtadv a couple of lines down.
-
Before blindly changing that script I looked around that area. Your patch is identical to last two lines of the generated script /var/etc/rtsold_XXX_script.sh. here is the whole block of interest
$rtsoldscript = "#!/bin/sh\n"; $rtsoldscript .= "# This shell script launches dhcp6c and configured gateways for this interface.\n"; $rtsoldscript .= "echo $2 > {$g['tmp_path']}/{$wanif}_routerv6\n"; $rtsoldscript .= "echo $2 > {$g['tmp_path']}/{$wanif}_defaultgwv6\n"; $rtsoldscript .= "/usr/bin/logger -t rtsold \"Recieved RA specifying route \$2 for interface {$interface}({$wanif})\"\n"; $rtsoldscript .= "if [ -f {$g['varrun_path']}/dhcp6c_{$wanif}.pid ]; then\n"; $rtsoldscript .= "\t/bin/pkill -F {$g['varrun_path']}/dhcp6c_{$wanif}.pid\n"; $rtsoldscript .= "\t/bin/sleep 1\n"; $rtsoldscript .= "fi\n"; $rtsoldscript .= "/usr/local/sbin/dhcp6c -d -c {$g['varetc_path']}/dhcp6c_{$interface}.conf -p {$g['varrun_path']}/dhcp6c_{$wanif}.pid {$wanif}\n"; $rtsoldscript .= "/usr/bin/logger -t rtsold \"Starting dhcp6 client for interface {$interface}({$wanif})\"\n"; /* Add wide-dhcp6c shell script here. Because we can not pass a argument to it. */ if (!@file_put_contents("{$g['varetc_path']}/rtsold_{$wanif}_script.sh", $rtsoldscript)) { printf("Error: cannot open rtsold_{$interface}_script.sh in interface_dhcpv6_configure() for writing.\n"); unset($rtsoldscript); return 1; } unset($rtsoldscript); @chmod("{$g['varetc_path']}/rtsold_{$wanif}_script.sh", 0755); /* accept router advertisements for this interface */ set_single_sysctl("net.inet6.ip6.accept_rtadv", "1"); log_error("Accept router advertisements on interface {$wanif} "); mwexec("/sbin/ifconfig {$wanif} inet6 accept_rtadv"); /* fire up rtsold for IPv6 RAs first, this backgrounds immediately. It will call dhcp6c */ if (isvalidpid("{$g['varrun_path']}/rtsold_{$wanif}.pid")) { killbypid("{$g['varrun_path']}/rtsold_{$wanif}.pid"); sleep(2); } mwexec("/usr/sbin/rtsold -1 -p {$g['varrun_path']}/rtsold_{$wanif}.pid -O {$g['varetc_path']}/rtsold_{$wanif}_script.sh {$wanif}");Now, if they are identical, question is why are the not doing what they are supposed to do? Adding them again, as patched, should not make difference. Unless there's problem in generated rtsold script. That made me look in my boot log and I've found these 3 lines
radvd[58467]: Exiting, failed to read config file. radvd[58467]: error parsing or activating the config file: /var/etc/radvd.conf radvd[58467]: syntax error in /var/etc/radvd.conf, line 11: /So, there's an error in that file and it's this
# Automatically Generated, do not edit # Generated for DHCPv6 Server wan interface hn0 { AdvSendAdvert on; MinRtrAdvInterval 5; MaxRtrAdvInterval 20; AdvLinkMTU 1500; AdvDefaultPreference low; AdvManagedFlag on; AdvOtherConfigFlag on; prefix / { DeprecatePrefix on; AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; route ::/0 { RemoveRoute on; }; DNSSL home { }; }; # Generated config for dhcp6 delegation from wan on lan interface hn1 { AdvSendAdvert on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; AdvLinkMTU 1500; AdvOtherConfigFlag on; prefix ::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; DNSSL home { }; };That prefix / line looks suspicious. It has no prefix and no length. Can anyone tell where are they suppose to come from?
-
How is your hn0 interface configured? That "prefix /" line looks to be impossible to obtain on stock source (granted I'm looking at 2.3 here, but don't think that specific area has changed). The variables that fill there are checked with is_ipaddrv6 earlier in that code block and it skips if that's false.
-
This is my WAN config:
-
Before blindly changing that script I looked around that area. Your patch is identical to last two lines of the generated script /var/etc/rtsold_XXX_script.sh. here is the whole block of interest
That's good, you should definitely have a look at the patch to understand what it's doing.
However, the key point that you're missing is that we've moved the launching of dhcp6c outside of the rtsold function.
rtsold is the "Router Solicitation Daemon" (why it's userland in FreeBSD is beyond me, but seems silly). Anywho, please see my post here for the explanation of why I added this additional call to dhcp6c before rtsold: https://forum.pfsense.org/index.php?topic=102008.msg603091#msg603091Now, if they are identical, question is why are the not doing what they are supposed to do? Adding them again, as patched, should not make difference. Unless there's problem in generated rtsold script. That made me look in my boot log and I've found these 3 lines
radvd[58467]: Exiting, failed to read config file. radvd[58467]: error parsing or activating the config file: /var/etc/radvd.conf radvd[58467]: syntax error in /var/etc/radvd.conf, line 11: /So, there's an error in that file and it's this
# Automatically Generated, do not edit # Generated for DHCPv6 Server wan interface hn0 { AdvSendAdvert on; MinRtrAdvInterval 5; MaxRtrAdvInterval 20; AdvLinkMTU 1500; AdvDefaultPreference low; AdvManagedFlag on; AdvOtherConfigFlag on; prefix / { DeprecatePrefix on; AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; route ::/0 { RemoveRoute on; }; DNSSL home { }; }; # Generated config for dhcp6 delegation from wan on lan interface hn1 { AdvSendAdvert on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; AdvLinkMTU 1500; AdvOtherConfigFlag on; prefix ::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; DNSSL home { }; };That prefix / line looks suspicious. It has no prefix and no length. Can anyone tell where are they suppose to come from?
Yup, that syntax looks odd. That section usually looks like "prefix ::/64" which will just start advertising RAs with whatever /64 has been assigned to that interface from the PD that that interface is "tracking".
However it's probably only throwing errors because you don't have an IA-PD delegated, and it hasn't had an IP assigned to that interface. So it's more of a symptom than a cause. -
This is my WAN config:
So hn0 is your WAN? What do you have configured under Services>DHCPv6/RA for WAN?
-
Yes, hn0 is my WAN.
As for DHCPv6/RA, this is what web page says
Services: DHCPv6 server
The DHCPv6 Server can only be enabled on interfaces configured with a static IPv6 address. This system has none.
I went and enables static IPv6 for WAN, then came back to DHCPv6 server page and everything was empty. Saved it anyways, re-enabled DHCPv6 for WAN, and error is gone. I checked /var/etc/radvd.conf file again, and that whole first configuration section is gone for interface hn0. Only part for hn0 (LAN) is there. I'm not sure if that's good or bad, as I said, but error is gone from log.
-
@det:
That's good, you should definitely have a look at the patch to understand what it's doing.
However, the key point that you're missing is that we've moved the launching of dhcp6c outside of the rtsold function.
rtsold is the "Router Solicitation Daemon" (why it's userland in FreeBSD is beyond me, but seems silly). Anywho, please see my post here for the explanation of why I added this additional call to dhcp6c before rtsold: https://forum.pfsense.org/index.php?topic=102008.msg603091#msg603091That patch did it. pfSense now picks up IPv6 after reboot and my LAN gets assigned public IPv6 addresses. Thanks.
