[Bug] IPv6: dhcp6c does not pick up advertised routes #1668

Space2Man · 2017-06-01T22:41:29Z

Hi,

I have upgraded to OPNsense 17.1.8 and everything is running fine except of IPv6 prefix delegation. My OPNsense box (running on a KVM virtual machine with vfio passthrough of a 4-port HP 364 NIC) is working fine except that the OPNsense box does not pick up an IPv6 delegation prefix from the FritzBox.

I am fighting with this since the early beginning of the 17.1 series. After IPv6 address renewal on the Fritzbox (which get's a /56 prefix from the provider) OPNsense does not pick up the new prefix. After a long time it seems to pick up the prefix at some point in time (at least 17.1.7 did :) ).

Find attached some network traces from both the FritzBox (LAN) and the OPNsense box (WAN).

Best regards,

Jochen (Space)

The text was updated successfully, but these errors were encountered:

Space2Man · 2017-06-02T09:22:24Z

Discussion about this topic is going on in

https://forum.opnsense.org/index.php?topic=5069.30

Space2Man · 2017-06-02T10:47:22Z

I found the reason why it's not working in my case ... OpenVPN also listens on UDP:546:

root@OPNvirt:/var/log # sockstat -l | grep :546
root     dhcp6c     33878 5  udp6   *:546                 *:*
root     openvpn    22884 5  udp6   *:546                 *:*

I stopped OpenVPN and immediately after next solicit request the IP was set.

Best regards,

Jochen

Space2Man · 2017-06-02T10:52:40Z

WTF -- to verify I have saved/applied interface WAN again while OpenVPN was stopped:

root@OPNvirt:/var/log # sockstat -l | grep :546
root     dhcp6c     60898 5  udp6   *:546                 *:*
root     sleep      72290 5  udp6   *:546                 *:*
root@OPNvirt:/var/log # ps aux | grep sleep
root   44525   0.0  0.1 1073972   2384  -  I    12:48      0:00.00 sleep 60
root   48040   0.0  0.1 1080488   2836  1  S+   12:48      0:00.00 grep sleep

And after the new address was set we have even more processes on 546:

root@OPNvirt:/var/log # sockstat -l | grep :546
root     sleep      62023 5  udp6   *:546                 *:*
root     sh         80338 5  udp6   *:546                 *:*
root     radvd      62980 5  udp6   *:546                 *:*
dhcpd    dhcpd      58578 5  udp6   *:546                 *:*
root     dhcp6c     60898 5  udp6   *:546                 *:*

Both sleep and sh belong to /var/db/rrd/updaterrd.sh ...

Space2Man · 2017-06-07T22:06:32Z

I don't know why but I think something is not working correctly with configd. See the open filedescriptors of these processes -- it seems as if the FDs 0-6 and 8,9 are shared between all these processes.

root@OPNvirt:/var/log # sockstat -l | grep ':546'
root     radvd      17860 8  udp6   *:546                 *:*
dhcpd    dhcpd      14157 8  udp6   *:546                 *:*
root     sleep      77366 8  udp6   *:546                 *:*
root     sh         47212 8  udp6   *:546                 *:*
root     dhcp6c     91012 8  udp6   *:546                 *:*
root@OPNvirt:/var/log # procstat -f 17860
  PID COMM                FD T V FLAGS    REF  OFFSET PRO NAME        
17860 radvd             text v r r-------   -       - -   /usr/local/sbin/radvd
17860 radvd              cwd v d r-------   -       - -   /                 
17860 radvd             root v d r-------   -       - -   /                 
17860 radvd                0 v c r-------   1       0 -   /dev/null         
17860 radvd                1 v c -w------   1       0 -   /dev/null         
17860 radvd                2 v c -w------   1       0 -   /dev/null         
17860 radvd                3 v r -w-----l  10       3 -   /var/run/configd.pid
17860 radvd                4 v c rw------  16       0 -   /dev/null         
17860 radvd                5 s - rw------  10       0 UDS /var/run/configd.socket
17860 radvd                6 s - rw------   6       0 UDS /var/run/configd.socket
17860 radvd                7 s - rw------   1       0 UDD /var/run/logpriv
17860 radvd                8 s - rw------   5       0 UDP ::.546 ::.0
17860 radvd                9 v r r-------   5     296 -   /var/etc/dhcp6c_wan.conf
17860 radvd               10 s - rw------   1       0 IP? ::.0 ::.0
root@OPNvirt:/var/log # sockstat -l | grep ':546' | grep sleep
root     sleep      77366 8  udp6   *:546                 *:*
root@OPNvirt:/var/log # procstat -f 77366
  PID COMM                FD T V FLAGS    REF  OFFSET PRO NAME        
77366 sleep             text v r r-------   -       - -   /bin/sleep        
77366 sleep              cwd v d r-------   -       - -   /                 
77366 sleep             root v d r-------   -       - -   /                 
77366 sleep                0 v c rw------   6       0 -   /dev/null         
77366 sleep                1 v c rw------   6       0 -   /dev/null         
77366 sleep                2 v c rw------   6       0 -   /dev/null         
77366 sleep                3 v r -w-----l  10       3 -   /var/run/configd.pid
77366 sleep                4 v c rw------  16       0 -   /dev/null         
77366 sleep                5 s - rw------  10       0 UDS /var/run/configd.socket
77366 sleep                6 s - rw------   6       0 UDS /var/run/configd.socket
77366 sleep                8 s - rw------   5       0 UDP ::.546 ::.0
77366 sleep                9 v r r-------   5     296 -   /var/etc/dhcp6c_wan.conf
root@OPNvirt:/var/log # procstat -f 47212
  PID COMM                FD T V FLAGS    REF  OFFSET PRO NAME        
47212 sh                text v r r-------   -       - -   /bin/sh           
47212 sh                 cwd v d r-------   -       - -   /                 
47212 sh                root v d r-------   -       - -   /                 
47212 sh                   0 v c rw------   6       0 -   /dev/null         
47212 sh                   1 v c rw------   6       0 -   /dev/null         
47212 sh                   2 v c rw------   6       0 -   /dev/null         
47212 sh                   3 v r -w-----l  10       3 -   /var/run/configd.pid
47212 sh                   4 v c rw------  16       0 -   /dev/null         
47212 sh                   5 s - rw------  10       0 UDS /var/run/configd.socket
47212 sh                   6 s - rw------   6       0 UDS /var/run/configd.socket
47212 sh                   8 s - rw------   5       0 UDP ::.546 ::.0
47212 sh                   9 v r r-------   5     296 -   /var/etc/dhcp6c_wan.conf
47212 sh                  10 v r r-------   1    5829 -   /var/db/rrd/updaterrd.sh

Space2Man · 2017-07-04T18:37:26Z

FYI: I have updated to 17.1.9 and it did not change the situation. As expected I still have to stop OpenVPN, then after some time IPv6 is configured and apinger, ntpd, ... and OpenVPN are restarted automatically.

ghost · 2017-07-18T12:59:27Z

I have the same problem here. I cant use openvpn because it uses port 546.
Someone with a solution here?

Space2Man · 2017-07-18T18:09:21Z

FYI: you can enable OpenVPN again ... only if you save an interface or restart OPNsense you have to stop OpenVPN service (leave it configured) and then OpenVPN service is started again automatically once the IPv6 address has been received.

Edit: fixed typo ... restart OPNsense ...

ghost · 2017-07-18T19:30:23Z

Hey!

thanks for your help.

when I activate openvpn (vpn/openvpn/uncheck deactivate) the openvpn service seems to be stopped and then my ipv6 connections gets lost.
How you activate openvpn on the same time?

Space2Man · 2017-07-18T20:53:12Z

Basically I do it like this (with OpenVPN enabled and running):

Save WAN interface --> Apply Changes
Go to Lobby --> Dashboard --> Services --> Stop OpenVPN

Then after some time I see in the Lobby that LAN interface has IPv6 address and dhcpd6, ntpd and openvpn services are started again.

Best regards,

Jochen

Space2Man · 2017-07-18T20:59:44Z

But this is only a workaround ... I am also waiting on this issue finally being fixed. Because sometimes IPv6 just stops working. Right now it's not that critical because most sites are not IPv6 only ... but that time will come ...

ghost · 2017-07-19T06:26:45Z

Thanks, I will try it!

ghost · 2017-07-19T17:06:57Z

That worked for me, thanks!

Space2Man · 2017-07-19T20:44:41Z

@fichtner Hi Franco,

do you have any idea why all these processes are listening on port udp:546 as well? My only guess is that these processes/shells are started somehow by configd and inherit the port somehow ... but this is FreeBSD, I am at home on Linux systems ... so I have no clue how to continue debugging.

OPNsense is the first time that I have access to a FreeBSD system and I really like OPNsense. If you want me to test something I surely can help.

Thanks a lot and best regards,

Jochen

fichtner · 2017-07-20T10:30:53Z

Hi Jochen,

Have been trying to find something in the OpenVPN code, but it does not seem to be a problem there at all. Configd seems unlikely, I've never heard of inheriting sockets before. Maybe some sort of fd leaking that we could prevent with FD_CLOEXEC ?

That would likely be in dhcp6c, it issues the reload via its script to /usr/local/etc/rc.newwanipv6

Cheers,
Franco

fichtner · 2017-07-20T10:39:45Z

@Space2Man just out of curiosity... can you try this?

REDACTED

fichtner · 2017-07-20T10:53:56Z

Try this one instead... it looks promising.

# opnsense-patch ea6b5bd

Space2Man · 2017-07-20T11:32:47Z

@fichtner I will test it tonight ... don't want to cut the route over which I am connecting while not at home :)

fichtner · 2017-07-20T11:35:27Z

@Space2Man sure, no problem. I can still see a stray sh / pyhton27 listening on 546 when configd_ctl.py is being called. There is something really fishy with dhcp6c (on FreeBSD 11), but now that is contained on the client side of the backend and the restart of services is not tainted anymore, which is what you said caused this in the first place. Fingers crossed :)

Space2Man · 2017-07-20T16:55:11Z

@fichtner Wohooo, patch applied, rebooted, logged in 5s after it responded to ping again ... and ... IPv6 address is set! Checked with sockstat ... no one else is listening ... save/apply on WAN interface, switch to Dashboard --> IPv6 is already there (same address as before). Find attached the logfile from a save:

Jul 20 18:50:26 OPNvirt dhcp6c[54979]: Start address release
Jul 20 18:50:26 OPNvirt dhcp6c[54979]: Sending Release
Jul 20 18:50:26 OPNvirt dhcp6c[54979]: remove an address 2a03:....../64 on em0
Jul 20 18:50:26 OPNvirt dhcp6c[54979]: dhcp6c Received RELEASE
Jul 20 18:50:26 OPNvirt dhcp6c[54979]: status code: success
Jul 20 18:50:27 OPNvirt dhcp6c[54979]: exiting
Jul 20 18:50:27 OPNvirt dhcp6c[46336]: failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Jul 20 18:50:27 OPNvirt dhcp6c[46336]: failed initialize control message authentication
Jul 20 18:50:27 OPNvirt dhcp6c[46336]: skip opening control port
Jul 20 18:50:28 OPNvirt dhcp6c[46445]: Sending Solicit
Jul 20 18:50:28 OPNvirt dhcp6c[46445]: unknown or unexpected DHCP6 option opt_86, len 16
Jul 20 18:50:29 OPNvirt dhcp6c[46445]: Sending Request
Jul 20 18:50:29 OPNvirt dhcp6c[46445]: unknown or unexpected DHCP6 option opt_86, len 16
Jul 20 18:50:29 OPNvirt dhcp6c[46445]: dhcp6c Received REQUEST
Jul 20 18:50:29 OPNvirt dhcp6c[46445]: add an address 2a03:..../64 on em0

This looks way better from my point of view ...

But do you have an idea how I can fix the issue with MTU I have? I have to setup mtu=1486 on my Linux boxes so they are able to connect to all IPv6 sites on the internet. Is dhcp6c maybe missing some part of the advertise where the MTU is included? Not sure what opt_86 is used for ...

Thanks a lot!

ghost · 2017-07-20T17:36:51Z

Thanks a lot Franco! works4me

Can I donate somewhere? ;)

fichtner · 2017-07-20T18:44:10Z

Thanks guys, that makes 3 positive tests. 😊 This is a workaround, I would like to find and fix the dhcp6c leak and plug it instead as the current fix could potentially deadlock configd. It's currently impossible, but we never know what we run into in the future. Jochen... maybe extra VLAN tag or IPv6 extension header in the way. You could clamp the value under firewall: settings: normalisation. Some people even suggest IPv6 as low as 12xx byte. The donation page is here... https://opnsense.org/donate/ Thanks! Franco

…

On 20. Jul 2017, at 19:36, zitlo ***@***.***> wrote: Thanks a lot Franco! works4me Can I donate somewhere? ;) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Space2Man · 2017-07-20T20:56:43Z

@fichtner I noticed one other thing ... for the first time now both LAN and WAN have a real IPv6 address ...

fichtner · 2017-07-21T05:58:42Z

@Space2Man I have seen this on my install as well, even before the fix. It's weird, but there was no downside here so I ignored it. Prefix-only on WAN mostly matters for the upstream DHCP, I think the address in this case comes from the delegated LAN prefix?

Space2Man · 2017-07-21T06:30:58Z

@fichtner LAN has 2a03:f580:c888:eef1:... and WAN has 2a03:f580:c888:ee00 ... not sure if it's from the same PD ... request goes for a /60 net.

Space2Man · 2017-07-21T06:34:09Z

But I can confirm that I am able to access IPv6 systems both direct from LAN and via Squid (which should use the WAN IP).

fichtner · 2017-07-21T06:34:17Z

in that case not, funky :)

ldldr · 2017-07-21T07:06:54Z

Thanks, I can confirm that dhcp6c is now the only process listening on port 546:

# sockstat -6l | grep -E ":546"
root     dhcp6c     97945 5  udp6   *:546                 *:*

However /var/etc/dhcp6c_opt1.conf is still not configured correctly for prefix delegation:

interface igb2 {
        script "/var/etc/dhcp6c_opt1_script.sh";
};

It seems that some statements in interfaces.inc are not evaluated, e. g.:

3172         if (is_numeric($wancfg['dhcp6-ia-pd-len'])) {                                                                                             
3173             $dhcp6cconf .= "  send ia-pd 0;  # request prefix delegation\n";                                                                      
3174         }

dhcp6-ia-pd-len is certainly numeric - /conf/config.xml looks like this:

<interfaces>                                                                                                                                         
  <opt1>                                                                                                                                             
    <ipaddrv6>dhcp6</ipaddrv6>                                                                                                                       
    <dhcp6-ia-pd-len>2</dhcp6-ia-pd-len>
    <dhcp6-ia-pd-send-hint>1</dhcp6-ia-pd-send-hint>
    <dhcp6prefixonly>1</dhcp6prefixonly>
    <dhcp6sendsolicit>1</dhcp6sendsolicit>
    <dhcp6usev4iface>1</dhcp6usev4iface>
    <adv_dhcp6_debug>1</adv_dhcp6_debug>
  </opt1>
</interfaces>

I verified that /var/etc/dhcp6c_opt1.conf is recreated when I make changes in the interface configuration. How can I debug this from the command line?

(cherry picked from commit ea6b5bd)

fichtner · 2017-07-21T07:26:45Z

@ldldr this is strange, it works from here, also it should always write something like "request domain-name-servers;" in the file. do you have local modifications?

ldldr · 2017-07-21T07:31:51Z

@fichtner not that I know of. How is interfaces.inc invoked? I'd like to debug this from the command line although I have not much experience with php. Is there a possibility to step through the code or watch variables as they get assigned like bash -x?

fichtner · 2017-07-21T07:35:28Z

Unfortunately not. Can you dump your interfaces.inc code in more detail?

It's really odd the config file has a closing "}" which it can only reach if all was executed, but it misses unconditional prints in between...

fichtner · 2017-07-21T07:36:31Z

I often debug using file_put_contents('/tmp/debugfile', @file_get_contents('tmp/debugfile') . "new message\n");

Space2Man · 2017-07-21T07:55:01Z

@ldldr Are you using Advanced Options for dhcp6c? Someone told me long time ago that Advanced Options are broken ...

ldldr · 2017-07-21T08:02:03Z

I verified that I have installed this version and yes I used advanced options to enable debugging. Without debugging it works:

interface igb2 {
  send ia-pd 0;  # request prefix delegation
        request domain-name-servers;
        request domain-name;
        script "/var/etc/dhcp6c_opt1_script.sh"; # we'd like some nameservers please
};
id-assoc pd 0 {
  prefix ::/62 infinity;
};

What is the problem with adv_dhcp6_debug?

fichtner · 2017-07-21T08:08:32Z

@ldldr do you mind sharing your config.xml portion again now to see what changed?

ldldr · 2017-07-21T08:12:48Z

I just noted that nothing has changed in the config.xml. Debugging is still enabled. The only thing that changed was that I selected basic before hitting save.

    <opt1>
      <if>igb2</if>
      <descr>WAN2</descr>
      <enable>1</enable>
      <spoofmac/>
      <ipaddr>192.168.178.254</ipaddr>
      <subnet>24</subnet>
      <gateway>WAN2GW</gateway>
      <ipaddrv6>dhcp6</ipaddrv6>
      <dhcp6-ia-pd-len>2</dhcp6-ia-pd-len>
      <dhcp6-ia-pd-send-hint>1</dhcp6-ia-pd-send-hint>
      <dhcp6prefixonly>1</dhcp6prefixonly>
      <dhcp6sendsolicit>1</dhcp6sendsolicit>
      <dhcp6usev4iface>1</dhcp6usev4iface>
      <adv_dhcp6_debug>1</adv_dhcp6_debug>
      <adv_dhcp6_interface_statement_send_options/>
      <adv_dhcp6_interface_statement_request_options/>
      <adv_dhcp6_interface_statement_information_only_enable/>
      <adv_dhcp6_interface_statement_script/>
      <adv_dhcp6_id_assoc_statement_address_enable/>
      <adv_dhcp6_id_assoc_statement_address/>
      <adv_dhcp6_id_assoc_statement_address_id/>
      <adv_dhcp6_id_assoc_statement_address_pltime/>
      <adv_dhcp6_id_assoc_statement_address_vltime/>
      <adv_dhcp6_id_assoc_statement_prefix_enable/>
      <adv_dhcp6_id_assoc_statement_prefix/>
      <adv_dhcp6_id_assoc_statement_prefix_id/>
      <adv_dhcp6_id_assoc_statement_prefix_pltime/>
      <adv_dhcp6_id_assoc_statement_prefix_vltime/>
      <adv_dhcp6_prefix_interface_statement_sla_id/>
      <adv_dhcp6_prefix_interface_statement_sla_len/>
      <adv_dhcp6_authentication_statement_authname/>
      <adv_dhcp6_authentication_statement_protocol/>
      <adv_dhcp6_authentication_statement_algorithm/>
      <adv_dhcp6_authentication_statement_rdm/>
      <adv_dhcp6_key_info_statement_keyname/>
      <adv_dhcp6_key_info_statement_realm/>
      <adv_dhcp6_key_info_statement_keyid/>
      <adv_dhcp6_key_info_statement_secret/>
      <adv_dhcp6_key_info_statement_expire/>
      <adv_dhcp6_config_advanced/>
      <adv_dhcp6_config_file_override/>
      <adv_dhcp6_config_file_override_path/>
    </opt1>

fichtner · 2017-07-21T08:18:32Z

ah, adv_dhcp6_config_advanced causes the other config to be overwritten:

https://github.com/opnsense/core/blob/master/src/etc/inc/interfaces.inc#L3162-L3165

ldldr · 2017-07-21T08:20:13Z

@fichtner now I see I have looked at the wrong place. $dhcp6cconf is set from DHCP6_Config_File_Advanced():

3208     // DHCP6 Config File Advanced                                               
3209     if ($wancfg['adv_dhcp6_config_advanced']) {                                 
3210         $dhcp6cconf = DHCP6_Config_File_Advanced($interface, $wancfg, $wanif);  
3211     }

fichtner · 2017-07-21T08:20:53Z

ack, I'll see what we can do about that

ldldr · 2017-07-21T08:21:08Z

oh, you were faster ;)

fichtner · 2017-07-21T08:21:42Z

it's called teamwork! :)

Space2Man · 2017-07-21T08:33:36Z

That's why I love open source :)

ldldr · 2017-07-21T08:51:56Z

I have this weird problem again: dhcp6c is listening on 546 but sending on a random port, 18892 this time:

# sockstat -6l | grep -E ":546"
root     dhcp6c     88527 5  udp6   *:546                 *:*

# tcpdump -i igb2 -vvvnn ip6 and port 547 or 546
10:46:51.580276 IP6 (hlim 1, next-header UDP (17) payload length: 105) fe80::ec4:7aff:fe7f:8412.18892 > ff02::1:2.547: [bad udp cksum 0x0a57 -> 0xe9e2!] dhcp6 solicit (xid=531ba3 (client-ID hwaddr/time type 1 time 553595220 0cc47a7f8410) (IA_NA IAID:0 T1:0 T2:0) (elapsed-time 1528) (option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/62 pltime:4294967295 vltime:4294967295)))
10:46:51.584780 IP6 (hlim 64, next-header UDP (17) payload length: 178) fe80::3a10:d5ff:fe6f:291f.547 > fe80::ec4:7aff:fe7f:8412.18892: [udp sum ok] dhcp6 advertise (xid=531ba3 (client-ID hwaddr/time type 1 time 553595220 0cc47a7f8410) (server-ID hwaddr type 1 3810d56f291f) (preference 0) (DNS-server fd00::3a10:d5ff:fe6f:291f) (opt_86) (IA_NA IAID:0 T1:1800 T2:2880 (IA_ADDR 2003:xx:xxxx:xx00:ec4:7aff:fe7f:8412 pltime:3600 vltime:7200)) (IA_PD IAID:0 T1:1800 T2:2880 (IA_PD-prefix 2003:xx:xxxx:xxf0::/62 pltime:3600 vltime:7200)))

The UDP checksum is also wrong even though I disabled hardware checksum offloading. Needless to say that dhcp6c does not see the reply to port 18892:

Jul 21 10:46:51 opnsense dhcp6c[88527]: Sending Solicit                    
Jul 21 10:46:51 opnsense dhcp6c[88527]: set client ID (len 14)             
Jul 21 10:46:51 opnsense dhcp6c[88527]: set identity association           
Jul 21 10:46:51 opnsense dhcp6c[88527]: set elapsed time (len 2)           
Jul 21 10:46:51 opnsense dhcp6c[88527]: set option request (len 4)         
Jul 21 10:46:51 opnsense dhcp6c[88527]: set IA_PD prefix                   
Jul 21 10:46:51 opnsense dhcp6c[88527]: set IA_PD                          
Jul 21 10:46:51 opnsense dhcp6c[88527]: send solicit to ff02::1:2%igb2     
Jul 21 10:46:51 opnsense dhcp6c[88527]: reset a timer on igb2, state=SOLICIT, timeo=4, retrans=16326

ldldr · 2017-07-21T10:33:23Z

I have another problem. radvd.pid is not created and radvd is started over and over again:

root@opnsense:~ # cat /var/run/radvd.pid
cat: /var/run/radvd.pid: No such file or directory

root@opnsense:~ # pgrep -fla radvd
57678 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog
45905 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog
16943 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog
2042 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog
73713 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog
60174 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog
35214 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog
19766 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog
81486 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog
71365 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog
57143 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog

ldldr · 2017-07-21T10:37:06Z

Please ignore the last post. This happens when radvd is started with the -d option. My fault.

fichtner · 2017-07-21T15:05:13Z

Fix has been merged to stable branches, will even hit 17.7.11.

Advanced config issue moved to #1735 to close this.

fichtner · 2017-07-21T15:05:34Z

Thanks everyone for helping to get this right! :)

Space2Man changed the title ~~IPv6: dhcp6c does not pick up advertised routes~~ [Bug] IPv6: dhcp6c does not pick up advertised routes Jul 19, 2017

fichtner added a commit that referenced this issue Jul 20, 2017

interfaces: protect call of new WAN IPv6 #1668

dbc5970

fichtner added a commit that referenced this issue Jul 20, 2017

interfaces: protect call of new WAN IPv6 #1668

ea6b5bd

fichtner self-assigned this Jul 20, 2017

fichtner added the bug Production bug label Jul 20, 2017

fichtner added this to the 17.7 milestone Jul 20, 2017

fichtner mentioned this issue Jul 20, 2017

[17.1.6] DHCPv6 Client bug #1629

Closed

fichtner added a commit that referenced this issue Jul 21, 2017

interfaces: protect call of new WAN IPv6 #1668

68e2c16

(cherry picked from commit ea6b5bd)

fichtner added a commit that referenced this issue Jul 21, 2017

interfaces: protect call of new WAN IPv6 #1668

786bc77

(cherry picked from commit ea6b5bd)

fichtner mentioned this issue Jul 21, 2017

interfaces: adv_dhcp6_config_advanced causes the other config to be overwritten #1735

Closed

fichtner closed this as completed Jul 21, 2017

[Bug] IPv6: dhcp6c does not pick up advertised routes #1668

[Bug] IPv6: dhcp6c does not pick up advertised routes #1668

Comments

Space2Man commented Jun 1, 2017

Space2Man commented Jun 2, 2017 • edited Loading

Space2Man commented Jun 2, 2017 • edited Loading

Space2Man commented Jun 2, 2017 • edited Loading

Space2Man commented Jun 7, 2017 • edited Loading

Space2Man commented Jul 4, 2017

ghost commented Jul 18, 2017

Space2Man commented Jul 18, 2017 • edited Loading

ghost commented Jul 18, 2017

Space2Man commented Jul 18, 2017

Space2Man commented Jul 18, 2017

ghost commented Jul 19, 2017

ghost commented Jul 19, 2017

Space2Man commented Jul 19, 2017

fichtner commented Jul 20, 2017

fichtner commented Jul 20, 2017 • edited Loading

fichtner commented Jul 20, 2017

Space2Man commented Jul 20, 2017

fichtner commented Jul 20, 2017

Space2Man commented Jul 20, 2017

ghost commented Jul 20, 2017

fichtner commented Jul 20, 2017 via email

Space2Man commented Jul 20, 2017

fichtner commented Jul 21, 2017

Space2Man commented Jul 21, 2017

Space2Man commented Jul 21, 2017

fichtner commented Jul 21, 2017

ldldr commented Jul 21, 2017

fichtner commented Jul 21, 2017

ldldr commented Jul 21, 2017

fichtner commented Jul 21, 2017

fichtner commented Jul 21, 2017

Space2Man commented Jul 21, 2017

ldldr commented Jul 21, 2017

fichtner commented Jul 21, 2017

ldldr commented Jul 21, 2017

fichtner commented Jul 21, 2017 • edited Loading

ldldr commented Jul 21, 2017

fichtner commented Jul 21, 2017

ldldr commented Jul 21, 2017

fichtner commented Jul 21, 2017

Space2Man commented Jul 21, 2017

ldldr commented Jul 21, 2017 • edited Loading

ldldr commented Jul 21, 2017

ldldr commented Jul 21, 2017

fichtner commented Jul 21, 2017

fichtner commented Jul 21, 2017

Space2Man commented Jun 2, 2017 •

edited

Loading

Space2Man commented Jun 2, 2017 •

edited

Loading

Space2Man commented Jun 2, 2017 •

edited

Loading

Space2Man commented Jun 7, 2017 •

edited

Loading

Space2Man commented Jul 18, 2017 •

edited

Loading

fichtner commented Jul 20, 2017 •

edited

Loading

fichtner commented Jul 21, 2017 •

edited

Loading

ldldr commented Jul 21, 2017 •

edited

Loading