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 section

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





  • @hda:

    https://forum.pfsense.org/index.php?topic=101967.msg601280#msg601280

    That doesn't fix the problem I described above.

    @753951:

    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:

    @753951:

    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?



  • @753951:

    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#L4010

    However 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:



  • @753951:

    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#msg603091

    @753951:

    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?

    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.



  • @753951:

    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#msg603091

    That patch did it. pfSense now picks up IPv6 after reboot and my LAN gets assigned public IPv6 addresses. Thanks.



  • @753951:

    That patch did it. pfSense now picks up IPv6 after reboot and my LAN gets assigned public IPv6 addresses. Thanks.

    Excellent, that's good to hear.
    It's by no means perfect.  rtsold will superfluously restart dhcp6c after you've already got a PD, but that shouldn't be too noticeable.  At least it triggers authentication with the ISP and lets you on the network.

    One thing, can you check your logs for any XID session mismatch/errors?  I don't think we'd be introducing any duplicate instances of dhcp6c by doing this, but just want to make sure.



  • @753951:

    This is my WAN config:

    Try this:  Use Interfaces-WAN with DHCP6 and DHCP6c conf:

    Check, Only request an IPv6 prefix, do not request an IPv6 address
    DHCPv6 Prefix Delegation size == 56
    Check, Send an IPv6 prefix hint to indicate the desired prefix size for delegation

    & check: Advanced config, it is no more than:
    (send options(ia-pd 0) and Prefix delegation = checked only).

    Then create Static LAN's config's i.s.o. Track Interface…



  • @753951:

    Yes, hn0 is my WAN.

    …re-enabled DHCPv6 for WAN...

    Only part for hn0 (LAN) is there...

    Makes no sense. DHCPv6/RA is about your LAN's.



  • @hda:

    @753951:

    Yes, hn0 is my WAN.

    …re-enabled DHCPv6 for WAN...

    Only part for hn0 (LAN) is there...

    Makes no sense. DHCPv6/RA is about your LAN's.

    Sorry. It was supposed to be "Only part for hn1 (LAN) is there…"



  • @det:

    One thing, can you check your logs for any XID session mismatch/errors?  I don't think we'd be introducing any duplicate instances of dhcp6c by doing this, but just want to make sure.

    Yes, there are four of them in the log after reboot. Here is pertinent part of the log (public IP addresses are mangled), if that helps

    dhcp6c[14001]: script "/var/etc/dhcp6c_wan_script.sh" terminated
    dhcp6c[14001]: removing an event on hn0, state=REQUEST
    dhcp6c[14001]: removing server (ID: 00:03:00:02:c0:d4:12:14:18:11)
    dhcp6c[14001]: got an expected reply, sleeping.
    dhcp6c[14001]: release an IA: PD-0
    dhcp6c[14001]: reset a timer on hn0, state=RELEASE, timeo=0, retrans=991
    dhcp6c[14001]: a new XID (acf098) is generated
    dhcp6c[14001]: set client ID (len 14)
    dhcp6c[14001]: set server ID (len 10)
    dhcp6c[14001]: set elapsed time (len 2)
    dhcp6c[14001]: set IA_PD prefix
    dhcp6c[14001]: set IA_PD
    dhcp6c[14001]: send release to ff02::1:2%hn0
    dhcp6c[14001]: remove an IA: PD-0
    dhcp6c[14001]: remove a site prefix 2001:fff:ffff:ca00::/56
    dhcp6c[14001]: remove an address 2001:fff:ffff:ca99:215:5dff:fe63:cc03/64 on hn1
    dhcp6c[14001]: reset a timer on hn0, state=INIT, timeo=0, retrans=793
    dhcp6c[14001]: removing an event on hn0, state=INIT
    dhcp6c[14001]: receive advertise from fe80::ea4:2ff:fe94:7801%hn0 on hn0
    dhcp6c[14001]: get DHCP option server ID, len 10
    dhcp6c[14001]: DUID: 00:03:00:02:c0:d4:12:14:18:11
    dhcp6c[14001]: get DHCP option client ID, len 14
    dhcp6c[14001]: DUID: 00:01:00:01:1e:3d:d6:32:01:18:5a:73:dc:02
    dhcp6c[14001]: get DHCP option IA_PD, len 41
    dhcp6c[14001]: IA_PD: ID=0, T1=86400, T2=144000
    dhcp6c[14001]: get DHCP option IA_PD prefix, len 25
    dhcp6c[14001]: IA_PD prefix: 2001:fff:ffff:ca00::/56 pltime=172800 vltime=345600
    dhcp6c[14001]: get DHCP option DNS, len 32
    dhcp6c[14001]: XID mismatch
    dhcp6c[14001]: receive advertise from fe80::ea4:2ff:fe94:7801%hn0 on hn0
    dhcp6c[14001]: get DHCP option server ID, len 10
    dhcp6c[14001]: DUID: 00:03:00:02:c0:d4:12:14:18:11
    dhcp6c[14001]: get DHCP option client ID, len 14
    dhcp6c[14001]: DUID: 00:01:00:01:1e:3d:d6:32:01:18:5a:73:dc:02
    dhcp6c[14001]: get DHCP option IA_PD, len 41
    dhcp6c[14001]: IA_PD: ID=0, T1=86400, T2=144000
    dhcp6c[14001]: get DHCP option IA_PD prefix, len 25
    dhcp6c[14001]: IA_PD prefix: 2001:fff:ffff:ca00::/56 pltime=172800 vltime=345600
    dhcp6c[14001]: get DHCP option DNS, len 32
    dhcp6c[14001]: XID mismatch
    dhcp6c[14001]: receive advertise from fe80::ea4:2ff:fe94:7801%hn0 on hn0
    dhcp6c[14001]: get DHCP option server ID, len 10
    dhcp6c[14001]: DUID: 00:03:00:02:c0:d4:12:14:18:11
    dhcp6c[14001]: get DHCP option client ID, len 14
    dhcp6c[14001]: DUID: 00:01:00:01:1e:3d:d6:32:01:18:5a:73:dc:02
    dhcp6c[14001]: get DHCP option IA_PD, len 41
    dhcp6c[14001]: IA_PD: ID=0, T1=86400, T2=144000
    dhcp6c[14001]: get DHCP option IA_PD prefix, len 25
    dhcp6c[14001]: IA_PD prefix: 2001:fff:ffff:ca00::/56 pltime=172800 vltime=345600
    dhcp6c[14001]: get DHCP option DNS, len 32
    dhcp6c[14001]: XID mismatch
    dhcp6c[14001]: receive advertise from fe80::ea4:2ff:fe94:7801%hn0 on hn0
    dhcp6c[14001]: get DHCP option server ID, len 10
    dhcp6c[14001]: DUID: 00:03:00:02:c0:d4:12:14:18:11
    dhcp6c[14001]: get DHCP option client ID, len 14
    dhcp6c[14001]: DUID: 00:01:00:01:1e:3d:d6:32:01:18:5a:73:dc:02
    dhcp6c[14001]: get DHCP option IA_PD, len 41
    dhcp6c[14001]: IA_PD: ID=0, T1=86400, T2=144000
    dhcp6c[14001]: get DHCP option IA_PD prefix, len 25
    dhcp6c[14001]: IA_PD prefix: 2001:fff:ffff:ca00::/56 pltime=172800 vltime=345600
    dhcp6c[14001]: get DHCP option DNS, len 32
    dhcp6c[14001]: XID mismatch
    dhcp6c[14001]: receive reply from fe80::ea4:2ff:fe94:7801%hn0 on hn0
    dhcp6c[14001]: get DHCP option server ID, len 10
    dhcp6c[14001]: DUID: 00:03:00:02:c0:d4:12:14:18:11
    dhcp6c[14001]: get DHCP option client ID, len 14
    dhcp6c[14001]: DUID: 00:01:00:01:1e:3d:d6:32:01:18:5a:73:dc:02
    dhcp6c[14001]: get DHCP option IA_PD, len 49
    dhcp6c[14001]: IA_PD: ID=0, T1=0, T2=0
    dhcp6c[14001]: get DHCP option status code, len 33
    dhcp6c[14001]: status code: success
    dhcp6c[14001]: executes /var/etc/dhcp6c_wan_script.sh
    php-fpm[277]: /rc.newwanipv6: rc.newwanipv6: Info: starting on hn0.
    php-fpm[277]: /rc.newwanipv6: rc.newwanipv6: on (IP address: fe80::215:5dff:fe63:cc02) (interface: wan) (real interface: hn0).
    unbound: [69580:0] info: service stopped (unbound 1.5.4).
    unbound: [69580:0] info: server stats for thread 0: 7 queries, 2 answers from cache, 5 recursions, 0 prefetch
    unbound: [69580:0] info: server stats for thread 0: requestlist max 17 avg 8 exceeded 0 jostled 0
    unbound: [69580:0] info: average recursion processing time 0.771420 sec
    unbound: [69580:0] info: histogram of recursion processing times
    unbound: [69580:0] info: [25%]=0 median[50%]=0 [75%]=0
    unbound: [69580:0] info: lower(secs) upper(secs) recursions
    unbound: [69580:0] info: 0.524288 1.000000 2
    unbound: [4200:0] notice: init module 0: validator
    unbound: [4200:0] notice: init module 1: iterator
    dhcpleases: Sending HUP signal to dns daemon(4200)
    unbound: [4200:0] info: start of service (unbound 1.5.4).
    unbound: [4200:0] info: service stopped (unbound 1.5.4).
    unbound: [4200:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch
    unbound: [4200:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
    unbound: [4200:0] notice: Restart of unbound 1.5.4.
    unbound: [4200:0] notice: init module 0: validator
    unbound: [4200:0] notice: init module 1: iterator
    unbound: [4200:0] info: start of service (unbound 1.5.4).
    dhcpleases: Sending HUP signal to dns daemon(4200)
    unbound: [4200:0] info: service stopped (unbound 1.5.4).
    unbound: [4200:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch
    unbound: [4200:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
    unbound: [4200:0] notice: Restart of unbound 1.5.4.
    unbound: [4200:0] notice: init module 0: validator
    unbound: [4200:0] notice: init module 1: iterator
    unbound: [4200:0] info: start of service (unbound 1.5.4).
    radvd[35097]: attempting to reread config file
    radvd[35097]: no auto-selected prefix on interface hn1, disabling advertisements
    radvd[35097]: sendmsg: Can't assign requested address
    radvd[35097]: resuming normal operation
    php-fpm[277]: /rc.newwanipv6: ROUTING: setting default route to d99-99-9-9.xxxx.xxxxx.xxx
    php-fpm[277]: /rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::ea4:2ff:fe94:7801%hn0
    apinger: SIGHUP received, reloading configuration.
    dhcp6c[14001]: script "/var/etc/dhcp6c_wan_script.sh" terminated
    dhcp6c[14001]: removing an event on hn0, state=RELEASE
    dhcp6c[14001]: exiting



  • If you want to switch to 2.3RC there are a couple of patches available that will fix  the issue with the XID's too. I'm keeping the patches reasonably up to date. If you do update and find the patches don't apply then pm me and I'll update them for you, otherwise a full fix for this is slated for 2.3.1

    The patches can be found here, always take the last ones in the attached files, there are two you'll need, interfaces.inc and interfaces.php.

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



  • cool, i'm glad people are having the same issue as me… I kinda forgot about the issue or that I even created this topic a while back.. until I rebooted my router to upgrade it to 2.3, :\ couldn't remember what was wrong, until I found my own thread haha!

    But apparently its still a problem in 2.3 , is there a patch now? or whats the status?

    Thanks



  • A proper fix is slated for 2.3.2

    In the meantime, if you tell me what version you are running I'll create a patch for you and post it.



  • I started a thread (https://forum.pfsense.org/index.php?topic=113461.0) about this yesterday, so as to not hijack this thread, but since I'm not the only one having problems with native /56, and I got no responses there, I'll ask here.

    My ISP requires the router to request a /56 using IA-PD, not IA-NA. If the router asks using both, it's supposed to accept the rejection of the IA-NA. Their router allocates itself a wan address in the ff subnet and uses the 00 subnet for the lan. I installed pfsense using "quick/easy install" but it did not work (i.e., no prefix was delegated and dhcp6 did not start. I'm not clear how to allocate a wan address in ff, nor how to allocate the lan subnet. Supposedly their edge router will send out an RA after the dhcp process completes. Their edge router apparently rejects RS messages for security reasons. I'm wondering if these idiosyncrasies are what's tripping up pfsense.



  • I had a discussion with an engineer from my ISP, which is Telus. He referred me to TR-124 - Issue 4, which uses the flow-chart below for configuring ipv6. They use that mechanism, except they have configured their edge routers to not respond to RA until DHCP is done. Based on what he said, I'm quite certain that the problems I'm having are the same as what det described above, which is that pfsense starts RS/RA before DHCP, so it hangs. While I'm not familiar enough with this issue to comment on other cases, for this specific case, it's pretty clear that pfsense needs an option to allow the RS/RA and DHCP processes to be forked so they operate concurrently and can complete in an arbitrary order.

    There is another requirement in TR-124 - Issue 4 that bears consideration.

    WAN.IPv6. 12 If the RG does not have a globally-scoped address on its WAN interface after having been delegated a prefix, it MUST create addresses for itself from the delegated prefix. It MUST have at least one address and MAY have more
    There is currently no algorithm defined for address creation. It should be assumed that different service providers will want different rules for how to create the address, how many addresses to create, and in the case of multiple addresses, how the different addresses are used.

    In the case of Telus, their gateway allocates its global WAN address in prefix+ff/64, using RFC 2464. It allocates prefix+00/64 for LAN addresses.

    Here are the settings from my gateway:

    IPv6 Prefix of Delegated: 2001:569:XXXX:8500::/56
    IPv6 WAN Status: Connected
    IPv6 WAN Address: 2001:569:XXXX:85ff:4e8b:30ff:fe19:f939/64
    IPv6 WAN Link Local Address: fe80::4e8b:30ff:fe19:f939
    IPv6 LAN Link Local Address: fe80::4e8b:30ff:fe19:f938

    For users who have ISPs using TR-124, it would be very useful if there was an option which could be in the DHCP6 advanced configuration settings for pfsense to auto-create a global WAN address in a user-specified prefix using RFS 2464.

    I'd appreciate comments on this. Should I post it in the thread for bug 5993?



  • Lol bimmer,
    its not probably the same issue, its the EXACT same issue with the Exact same provider :)

    just run in manually or run the manual patch as some suggested above or wait for 2.3.2 for proper fix :)



  • I tried to install patch 3102 for this issue, but I run into a 'this patch can't be applied cleanly' error.

    Can anyone advise how to install on 2.3.2?

    Error text:

    /usr/bin/patch --directory=/ -t -p2 -i /var/patches/57b8e16425366.patch --check --forward --ignore-whitespace
    
    Hmm...  Looks like a unified diff to me...
    The text leading up to this was:
    --------------------------
    |From efc042acd68e86e3b6c6eb0b3fbdc82ef7d17dc6 Mon Sep 17 00:00:00 2001
    |From: marjohn56 
    |Date: Sun, 7 Aug 2016 21:06:25 +0100
    |Subject: [PATCH] DHCP6 Before RA. Additions and ammendments
    |
    |Replaced posix_kill() in kill_dhcp6client_process() with mwexec("kill -9 $pid"), this is because the posix_kill call was not reliably killing the dhcp6c process, kill -9 works every time.
    |
    |Changes to the rtsold script creation. The script lines starting dhcp6c should not have be written to the script when dhcpwithoutra is true.
    |
    |Style corrections, I spend more time doing these than changing code!
    |---
    | src/etc/inc/interfaces.inc | 41 +++++++++++++++--------------------------
    | 1 file changed, 15 insertions(+), 26 deletions(-)
    |
    |diff --git a/src/etc/inc/interfaces.inc b/src/etc/inc/interfaces.inc
    |index 865009a..03929f2 100644
    |--- a/src/etc/inc/interfaces.inc
    |+++ b/src/etc/inc/interfaces.inc
    --------------------------
    Patching file etc/inc/interfaces.inc using Plan A...
    Hunk #1 succeeded at 1332 (offset 32 lines).
    Hunk #2 failed at 3058.
    Hunk #3 failed at 3997.
    Hunk #4 failed at 4008.
    Hunk #5 failed at 4032.
    4 out of 5 hunks failed while patching etc/inc/interfaces.inc
    done
    


  • @rancid-lemon:

    I tried to install patch 3102 for this issue, but I run into a 'this patch can't be applied cleanly' error.

    Can anyone advise how to install on 2.3.2?

    PR 3102 hasn't been backported to 2.3.2 (yet, I hope). If you want to run the patches, you need to run the development snapshot. I'm running PRs 3102/1, 3102/2, 3103, 3105, 3106 and 3107 and they are working quite well. The only patches that are specifically for the RA issue are 3102/1 and 3102/2. The rest are for dhcp6. Refer to https://redmine.pfsense.org/issues/5993 and https://github.com/pfsense/pfsense/pulls. The shapshot already has an earlier version of the fix, so it should get a prefix even without the PRs.



  • @bimmerdriver:

    @rancid-lemon:

    I tried to install patch 3102 for this issue, but I run into a 'this patch can't be applied cleanly' error.

    Can anyone advise how to install on 2.3.2?

    PR 3102 hasn't been backported to 2.3.2 (yet, I hope). If you want to run the patches, you need to run the development snapshot. I'm running PRs 3102/1, 3102/2, 3103, 3105, 3106 and 3107 and they are working quite well. The only patches that are specifically for the RA issue are 3102/1 and 3102/2. The rest are for dhcp6. Refer to https://redmine.pfsense.org/issues/5993 and https://github.com/pfsense/pfsense/pulls. The shapshot already has an earlier version of the fix, so it should get a prefix even without the PRs.

    Understood, thank you for the explanation. I will give the snapshot a go and see how I get on before installing the patches, will keep an eye on this thread too.



  • @rancid-lemon:

    @bimmerdriver:

    @rancid-lemon:

    I tried to install patch 3102 for this issue, but I run into a 'this patch can't be applied cleanly' error.

    Can anyone advise how to install on 2.3.2?

    PR 3102 hasn't been backported to 2.3.2 (yet, I hope). If you want to run the patches, you need to run the development snapshot. I'm running PRs 3102/1, 3102/2, 3103, 3105, 3106 and 3107 and they are working quite well. The only patches that are specifically for the RA issue are 3102/1 and 3102/2. The rest are for dhcp6. Refer to https://redmine.pfsense.org/issues/5993 and https://github.com/pfsense/pfsense/pulls. The shapshot already has an earlier version of the fix, so it should get a prefix even without the PRs.

    Understood, thank you for the explanation. I will give the snapshot a go and see how I get on before installing the patches, will keep an eye on this thread too.

    In case you didn't notice, if you upgrade to the latest 2.3.3 development snapshot, all of the pertinent patches have already been merged.