IPv6 Rapid deployment option malfunctioning

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Enable ipv6rd

What is the expected output? What do you see instead?
Working IPv6

What version of the product are you using?
RT-N12-1.9.2.7-rtn-r3497.trx

Please provide any additional information below.
My IPS uses DNCP option 212 as described in
http://tools.ietf.org/html/rfc5969
So it sends data in format 
option option-6rd code 212 = { integer 8, integer 8, integer 16, integer 16, 
integer 16, integer 16, integer 16, integer 16, integer 16, integer 16, array 
of ip-address };
This hook on Debian stable ISC DHCP able to extract that data via hook
http://www.litech.org/6rd/dhclient-6rd
http://www.litech.org/6rd/
All information needed is send in DHCP, therefore field "6RD IPv4 border 
router:" must be optional (for NON 212 RD ISPs or ones who does't send it DHSP, 
like comcast)

Here is working example for openwrt 
http://www.beloin.net/doc/videotron_6rd.html
I did test with my friend router and it worked, but I would like to have it 
working on "renewed Oleg's firmware".

I'm available to do any tests needed.

Original issue reported on code.google.com by unix....@gmail.com on 17 Nov 2011 at 2:15

[GoogleCodeExporter]

6rd via DHCP is disabled yet due we had no testers for this.
Can you confirm, that 6rd is working with manual settings? 

Original comment by themiron.ru on 17 Nov 2011 at 7:39

[GoogleCodeExporter]

On Thu, 17 Nov 2011 07:39:53 +0000

While it does *something* , it assigns totally wrong addresses.
If you can poin how can I see raw data from udcpc (lease file or some
special variables) and explain how it passed forward to IP assignment
(rc binary ? which function in code?) that would be good.
I see address inet6 8504:de2a::/128 scope global assigned on
six0@NONE but it should be  2607:fa48:N:N:: 

I can do any tests needed or even rebuild with any patches if you have
tutorial on how to setup build environment.

Original comment by unix....@gmail.com on 18 Nov 2011 at 12:57

[GoogleCodeExporter]

actually, now only ISP prefix is assigned, without any subnet ids
work is in progress, please take patience

Original comment by themiron.ru on 19 Nov 2011 at 1:42

• Changed state: Accepted

[GoogleCodeExporter]

Problem exits in version r3702 as well.

Original comment by unix....@gmail.com on 29 Dec 2011 at 4:44

[GoogleCodeExporter]

I'm getting inet6 2607:fa48:NNNN:NNNN::/42 scope global on six0@NONE
and ipv6 internet is pingable from router itself which is good.
LAN still broken. 

Original comment by unix....@gmail.com on 29 Dec 2011 at 5:13

[GoogleCodeExporter]

Ok, I've found why 6rd has wrong mask applied
According the specification
http://tools.ietf.org/html/rfc5969 page five we have do
32-ip6rd_ipv4masklen+ip6rd_6rdprefixlen
but in the code udhcpc.c we have lines

                        snprintf(addrstr, sizeof(addrstr), "%s/%s", values[2], values[1]);
                        nvram_set(strcat_r(prefix, "ipv6_addr", tmp), addrstr);

which means we are applying mask=ip6rd_6rdprefixlen instead of formula above.

Original comment by unix....@gmail.com on 29 Dec 2011 at 4:02

[GoogleCodeExporter]

Thank for you efforts. Could you provide nvram variables values:

nvram get ipv6_ip4size
nvram get ipv6_addr
nvram get ipv6_relay

?

Original comment by lly.dev on 29 Dec 2011 at 5:08

[GoogleCodeExporter]

Ok, here is:

--- rc/udhcpc.c.orig    2011-12-29 16:46:34.852054889 +0000
+++ rc/udhcpc.c 2011-12-29 18:22:41.578554748 +0000
@@ -158,9 +158,12 @@
            values[i] = strsep(&value, " ");
        if (i == 4) {
            nvram_set(strcat_r(prefix, "ipv6_ip4size", tmp), values[0]);
-           snprintf(addrstr, sizeof(addrstr), "%s/%s", values[2], values[1]);
+           snprintf(addrstr, sizeof(addrstr), "%s/%s", values[2], values[1]); 
            nvram_set(strcat_r(prefix, "ipv6_addr", tmp), addrstr);
            nvram_set(strcat_r(prefix, "ipv6_relay", tmp), values[3]);
+           snprintf(addrstr, sizeof(addrstr), "%s/64", values[2]); 
+           nvram_set("lan_ipv6_addr", addrstr);
+           nvram_set("ipv6_lan_addr", addrstr);
        }
    }
 #endif

Bombastically I set ipv6_lan_addr and lan_ipv6_addr with ipv6_range/64 values.
No need to change mask to the value from formula from the RFC, looks like it 
neede only if kernel with full ipv6rd and corresponding ip util.
This formula is still needed to validate that we got 64 or more range, 
otherwise applying /64 mask on lan interface will not work. 

Original comment by unix....@gmail.com on 29 Dec 2011 at 6:45

[GoogleCodeExporter]

Here are the values with patch

$ nvram show | grep ipv6
size: 17257 bytes (15511 left)
ipv6_6rd_ip4size=0
ipv6_lan_addr=2607:fa48:NNNN:0000:0000:0000:0000:0000/64
wan0_ipv6_ip4size=14
ipv6_dns1_x=
ipv6_sit_ttl=64
ipv6_dnsenable_x=0
ipv6_radvd_dns1_x=
wan0_ipv6_dns=
ipv6_if_x=0
wan0_ipv6_relay=24.YYY.XXX.1
ipv6_wanauto_x=0
ipv6_6rd_router=
ipv6_proto=tun6rd
ipv6_wan_router=
ipv6_lan_netsize=64
ipv6_lanauto_x=0
ipv6_wan_netsize=64
ipv6_sit_remote=
wan0_ipv6_addr=2607:fa48:NNNN:0000:0000:0000:0000:0000/42
ipv6_dns3_x=
lan_ipv6_addr=2607:fa48:NNNN:PPPP::/64
wan0_ipv6_proto=tun6rd
wan0_ipv6_if_x=0
ipv6_radvd_enable=1
ipv6_dns2_x=
ipv6_sit_relay=192.88.99.1
wan0_ipv6_addr_t=2607:fa48:NNNN:PPPP::/42
wan0_ipv6_router=
ipv6_wan_addr=
wan0_ipv6_remote=any
ipv6_sit_mtu=1280

Original comment by unix....@gmail.com on 29 Dec 2011 at 6:48

[GoogleCodeExporter]

Here is the DHCP reply while debugging with Debian box

14 42 2607:FA48:6E00:0000:0000:0000:0000:0000 96.23.219.1

So firmware applies /42 mask, while rfc mandates 32-14+42=60

I've tried /60 on firmware - does't work, while direct /42 works, on Debian - 
other way around.

Original comment by unix....@gmail.com on 29 Dec 2011 at 6:52

[GoogleCodeExporter]

I did couple of diffs below to check ipv6rd, after that I was able to use 
ipv6rd, bot  on LAN and WI-FI. The problem is that unfortunately WPA/WAP2 
doesn't work for me with self compiled sources from the morning trunk, while 
r3702 image from download section works with WPA2. Am I missing something? Any 
help would be appreciated. I understand that patches below are now way even 
close to production quality, but at least I was able troubleshoot something.

# diff -u rc/udhcpc.c.orig  rc/udhcpc.c
--- rc/udhcpc.c.orig    2011-12-29 16:46:34.852054889 +0000
+++ rc/udhcpc.c 2011-12-29 19:55:15.715804831 +0000
@@ -158,9 +158,13 @@
            values[i] = strsep(&value, " ");
        if (i == 4) {
            nvram_set(strcat_r(prefix, "ipv6_ip4size", tmp), values[0]);
-           snprintf(addrstr, sizeof(addrstr), "%s/%s", values[2], values[1]);
+           snprintf(addrstr, sizeof(addrstr), "%s/%s", values[2], values[1]); 
            nvram_set(strcat_r(prefix, "ipv6_addr", tmp), addrstr);
            nvram_set(strcat_r(prefix, "ipv6_relay", tmp), values[3]);
+           /* snprintf(addrstr, sizeof(addrstr), "%s/64", values[2]); */
+           snprintf(addrstr, sizeof(addrstr), "%s", values[2]); 
+           nvram_set("lan_ipv6_addr", addrstr);
+           nvram_set("ipv6_lan_addr", addrstr);
        }
    }
 #endif

# diff -u rc/services_ex.c.orig rc/services_ex.c
--- rc/services_ex.c.orig   2011-12-29 19:02:06.330305862 +0000
+++ rc/services_ex.c    2011-12-30 01:58:25.658804753 +0000
@@ -331,11 +331,21 @@
 #endif

    /* Prefix */
+    if (nvram_match("ipv6_proto", "tun6rd")) {
+       char *radvd_subnet;
+       radvd_subnet=nvram_safe_get("ipv6_lan_addr");
+       
+       fprintf(fp,
+                    "prefix %s {"
+                        "AdvOnLink on;"
+                        "AdvAutonomous on;", radvd_subnet);
+
+   } else {
    fprintf(fp,
            "prefix %s/%d {"
            "AdvOnLink on;"
            "AdvAutonomous on;", addrstr, size);
-
+   }
    if (nvram_match("ipv6_proto", "tun6to4"))
    {
        char *wan_ifname;
@@ -371,8 +381,8 @@
        dnsstr = nvram_safe_get("ipv6_lan_addr");
    if (dnsstr && *dnsstr)
    {
-       fprintf(fp,
-           "RDNSS %s {};", dnsstr);
+       /*  fprintf(fp,
+           "RDNSS %s {};", dnsstr); */
    }

    fprintf(fp, "};");

# diff -u rc/network.c.orig rc/network.c
--- rc/network.c.orig   2011-12-29 17:42:45.870304533 +0000
+++ rc/network.c    2011-12-29 21:36:54.471304351 +0000
@@ -1611,6 +1611,7 @@
            if (*lan6_ipaddr)
                eval("ip", "-6", "addr", "del", lan6_ipaddr, "dev", lan6_ifname);
            nvram_set("lan_ipv6_addr", addrstr);
+           nvram_set("ipv6_lan_addr", addrstr);
        }
        eval("ip", "-6", "addr", "add", addrstr, "dev", lan6_ifname);

Original comment by unix....@gmail.com on 30 Dec 2011 at 2:39

[GoogleCodeExporter]

First of all, thanks for raw data from debian, we need unmodified data from 
ISP. Unfortunately, we hasn't such ISP to experiment ourselves.

Second, please be patient - it is Christmas & New year vacations now :-)

As I can understand right, /60 works well on Debian, isn't it? If yes, can you 
provide ifconfig & route table from it? We mustn't violate standards.

Regarding WPA2 question - we haven't sources of wl driver(Wi-Fi) & it's 
user-space daemons - nas & eapd at all. It is Broadcom policy :( Thus, it is 
very hard to say whats going wrong on your side.
Moreover, Wi-Fi driver don't know anything about IPv6 and nas & eapd can't work 
in case of IPv4 disabled.

About patches - seems to be we have to eliminate difference between 
lan_ipv6_addr & ipv6_lan_addr nvram variables first. After that implement /60 
working solution.

Original comment by lly.dev on 30 Dec 2011 at 8:51

• Changed state: Started

[GoogleCodeExporter]

Here are data from Debian testing, Debian stable doesn't work since kernel and 
user space lacks 6rd support. eth0 - WAN, eth1 - LAN

#  ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2607:fa48:6d21:50d0::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::250:8dff:fe9d:7537/64 scope link 
       valid_lft forever preferred_lft forever
6: 6rdif: <NOARP,UP,LOWER_UP> mtu 1480 
    inet6 2607:fa48:6d21:50d0::1/60 scope global 
       valid_lft forever preferred_lft forever
    inet6 ::24.202.21.13/128 scope global 
       valid_lft forever preferred_lft forever

# ip -6 ro
::/96 via :: dev 6rdif  metric 256 
2607:fa48:6d21:50d0::/64 dev eth0  proto kernel  metric 256 
2607:fa48:6d21:50d0::/60 dev 6rdif  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev 6rdif  proto kernel  metric 256 
default via ::24.203.255.1 dev 6rdif  metric 1 

DHCP data raw: 
"14 42 2607:FA48:6d00:0000:0000:0000:0000:0000 24.203.255.1"
DHCP parsed data:
"6rd-prefix 2607:fa48:6d00::/42 6rd-relay_prefix 24.200.0.0/14 br 24.203.255.1"

Then parsed data goes to:

ip tunnel add 6rdif mode sit local $WANIP4
ip tunnel 6rd dev 6rdif 6rd-prefix ${srd_prefix}/${srd_prefixlen} 
6rd-relay_prefix ${srd_relayprefix}/${srd_masklen}
ip link set dev 6rdif up
ip -6 addr add "$ifname_ip6addr" dev 6rdif
ip -6 route add default via ::${srd_braddr} dev 6rdif metric 1
ip -6 addr add $lan_ip6addr dev $LANIF

Thanks for you help!

Original comment by unix....@gmail.com on 30 Dec 2011 at 2:53

[GoogleCodeExporter]

Sorry for confusion, surely  eth1 - WAN, eth0 - LAN

Original comment by unix....@gmail.com on 30 Dec 2011 at 4:06

[GoogleCodeExporter]

thanks for debugging, it's known issue about 6rd&dhcp
will look into soon.

Original comment by themiron.ru on 9 Jan 2012 at 7:57

[GoogleCodeExporter]

any news? does it work since r5214?
http://asus.vectormm.net/rtn/5222/

Original comment by themiron.ru on 4 Aug 2013 at 1:42

• Changed state: Fixed