Native IPv6 Not Working on Barrier Breaker

[johnllyon@…]

I had previously reopened ticket number 13879 because my google searching had shown I had the same symptoms. However, because I am not using 6in4, I was instructed to open a new ticket.

System:

Ar71xxx (WNDR3700v1) running the latest build (June 12, 2014). However, this problem has been reproduced in earlier builds (e.g. May 29, 2014 and several other May builds).

Symptoms:

Cannot ping or traceroute to IPv6 addresses, although it appears that I can resolve AAAA domain records to the corresponding IPv6 address just fine. For example, when I do "ping6 www.google.com" or ping -6 www.google.com" as root, I get the following error messages:

root@OpenWrt:~# ping6 www.google.com
PING www.google.com (2607:f8b0:4002:c06::69): 56 data bytes
ping6: sendto: Operation not permitted
root@OpenWrt:~# ping -6 www.google.com
PING www.google.com (2607:f8b0:4002:c06::69): 56 data bytes
ping: sendto: Operation not permitted

I would also note that devices on my network are unable to access the public internet using IPv6. I suspect that this may be related.

My /etc/config/network file is:

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config interface 'lan'
        option ifname 'eth0'
        option type 'bridge'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '192.168.99.1'
        option ip6assign '64'

config interface 'wan'
        option ifname 'eth1'
        option _orig_ifname 'eth1'
        option _orig_bridge 'false'
        option proto 'dhcp'

config interface 'wan6'
        option ifname '@wan'
        option proto 'dhcpv6'

config switch
        option name 'rtl8366s'
        option reset '1'
        option enable_vlan '1'
        option blinkrate '2'
        option max_length '3'
        option enable_vlan4k '1'

config switch_vlan
        option device 'rtl8366s'
        option vlan '1'
        option ports '0 1 2 3 5'

config switch_port
        option device 'rtl8366s'
        option port '1'

The redacted output of ifstatus wan6 is:

root@OpenWrt:~# ifstatus wan6
{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "uptime": 568,
        "l3_device": "eth1",
        "proto": "dhcpv6",
        "device": "eth1",
        "updated": [
                "addresses",
                "prefixes",
                "data"
        ],
        "metric": 0,
        "delegation": true,
        "ipv4-address": [

        ],
        "ipv6-address": [
                {
                        "address": "2001:558:6011:76:####:####:####:####",
                        "mask": 128,
                        "preferred": 3032,
                        "valid": 3032
                }
        ],
        "ipv6-prefix": [
                {
                        "address": "2601:0:bb40:5d::",
                        "mask": 64,
                        "preferred": 3032,
                        "valid": 3032,
                        "class": "wan6",
                        "assigned": {
                                "lan": {
                                        "address": "2601:0:bb40:5d::",
                                        "mask": 64
                                }
                        }
                }
        ],
        "ipv6-prefix-assignment": [

        ],
        "route": [

        ],
        "dns-server": [
                "2001:558:feed::1",
                "2001:558:feed::2"
        ],
        "dns-search": [

        ],
        "inactive": {
                "ipv4-address": [

                ],
                "ipv6-address": [

                ],
                "route": [

                ],
                "dns-server": [

                ],
                "dns-search": [

                ]
        },
        "data": {
                "passthru": "0017002020010558feed0000000000000000000120010558feed00000000000000000002"
        }
}

Please let me know if there is any other information I can provide.

[anonymous]

This looks like there are no routes received. So either the ISP sends no or invalid Router Advertisements or it does send valid ones but OpenWrt fails to parse them. We'd need a tcpdump of icmp6 traffic or a capture with radvdump or similar to see which of these is the case.

[johnllyon@…]

TCPDump file of all ipv6 traffic through WAN interface

[johnllyon@…]

I just uploaded a tcpdump of my WAN interface. I filtered it for all ip6 traffic using the command tcpdump ip6 -i eth1 -w tcpdump.out (where eth1 is my WAN interface). Looking at the tcpdump, it appears to have captured some icmp6 traffic including router advertisements.

I hope this helps. Please let me know if you need any additional information.

Thanks for the help!

[cyrus]

Thanks. The Router Advertisements itself look good at a first glance. The only thing that is strange is the source MAC-address which is 00:00:00:00:00:XX. Hmm seems I have to look into this further at some point. I mean in general RA parsing works otherwise I would have a ton of similar bugreports here. So now as to find out whats special abour yours / your ISP's.

[apple4ever]

tcpdump of ipv6 issue on Comcast connection

[apple4ever]

I have this exact same problem, and I thought I was going crazy. I attached a tcpdump output just like johnllyon@ and below is my config. I hope this info helps get this fixed.

/etc/config/network:

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config interface 'lan'
        option type 'bridge'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '192.168.0.1'
        option broadcast '192.168.0.255'
        option dns '192.168.0.51 192.168.0.52'
        option _orig_ifname 'eth0.1 radio0.network1 radio1.network1'
        option _orig_bridge 'true'
        option ifname 'eth0.1'
        option ip6assign '64'

config interface 'wan'
        option _orig_ifname 'eth1'
        option _orig_bridge 'false'
        option ifname 'eth1'
        option proto 'dhcp'

config switch
        option name 'rtl8366s'
        option reset '1'
        option enable_vlan '1'
        option blinkrate '2'

config switch_vlan
        option device 'rtl8366s'
        option vlan '1'
        option ports '0 1 2 3 5t'

config switch_port
        option device 'rtl8366s'
        option port '1'
        option led '6'

config switch_port
        option device 'rtl8366s'
        option port '2'
        option led '9'

config switch_port
        option device 'rtl8366s'
        option port '5'
        option led '2'

config interface 'wan6'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        option ifname '@wan'

ifstatus wan6:

{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "uptime": 214240,
        "l3_device": "eth1",
        "proto": "dhcpv6",
        "device": "eth1",
        "metric": 0,
        "delegation": true,
        "ipv4-address": [

        ],
        "ipv6-address": [
                {
                        "address": "2001:558:6031:XXXX:XXXX:XXXX:XXXX:XXXX",
                        "mask": 128,
                        "preferred": 283562,
                        "valid": 283562
                }
        ],
        "ipv6-prefix": [
                {
                        "address": "2601:1:2f80:XXXX::",
                        "mask": 64,
                        "preferred": 283562,
                        "valid": 283562,
                        "class": "wan6",
                        "assigned": {
                                "lan": {
                                        "address": "2601:1:2f80:XXXX::",
                                        "mask": 64
                                }
                        }
                }
        ],
        "ipv6-prefix-assignment": [

        ],
        "route": [

        ],
        "dns-server": [
                "2001:558:feed::2",
                "2001:558:feed::1"
        ],
        "dns-search": [

        ],
        "inactive": {
                "ipv4-address": [

                ],
                "ipv6-address": [

                ],
                "route": [

                ],
                "dns-server": [

                ],
                "dns-search": [

                ]
        },
        "data": {

        }
}

[neutronscott]

I reopened ticket #12888 for this, since it had a good description and I had not seen this ticket. Sorry.

I use Time Warner Cable and a ubee u10c018 cable modem.

odhcp6c must send a router solicitation, because I receive 1 RA which has a lifetime of 1800s. Either my ISP or my modem doesn't send RAs without a RS. So 30min later I have no default routes. "ip -6 route show" doesn't show this timeout for the routes, though it's exactly 30min later every time and that's the router lifetime in the RA.

18:03:51.406064 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 8) fe80::3246:9aff:fefe:4b59 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 8
18:03:51.438469 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 128) fe80::217:10ff:fe88:3097 > fe80::3246:9aff:fefe:4b59: [icmp6 sum ok] ICMP6, router advertisement, length 128
        hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
          source link-address option (1), length 8 (1): 00:17:10:88:30:97
          mtu option (5), length 8 (1):  1500
          prefix info option (3), length 32 (4): 2606:a000:c01:54::/64, Flags [onlink], valid time infinity, pref. time infinity
          prefix info option (3), length 32 (4): 2606:a000:efc0:54::/64, Flags [onlink], valid time infinity, pref. time infinity
          prefix info option (3), length 32 (4): 2606:a000:401:103::/64, Flags [onlink], valid time infinity, pref. time infinity

At the moment I have this in my crontab

root@OpenWrt:~# crontab -l
0 10 * * * wifi restart
*/10 * * * * /tmp/usr/bin/rdisc6 eth1 >/dev/null 2>&1

So far connectivity is good. odhcp6c sends an ra-updated event to dhcpv6.script and the routes live on.

I'm not sure the correct way, but other possible solutions (untested)

1. change accept_ra=2 in /proc/sys/net/ipv6/conf/all to override the default behaviour of turning off solicitations
2. have odhcp6c add the default route indefinitely
3. have odhcp6c send the RS

[erik@…]

Running BB r41737 with default config IPv6 does not work from nodes on network.

Works fine form the router:

root@OpenWrt:/# ping6 google.com
PING google.com (2607:f8b0:4005:802::100e): 56 data bytes
64 bytes from 2607:f8b0:4005:802::100e: seq=0 ttl=58 time=10.946 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 10.946/10.946/10.946 ms

ifstatus wan6

root@OpenWrt:/# ifstatus wan6
{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "uptime": 408,
        "l3_device": "eth0.2",
        "proto": "dhcpv6",
        "device": "eth0.2",
        "metric": 0,
        "delegation": true,
        "ipv4-address": [
                
        ],
        "ipv6-address": [
                {
                        "address": "2604:5500:f:11:c24a:ff:fedd:53ba",
                        "mask": 64,
                        "preferred": 604713,
                        "valid": 2591913
                }
        ],
        "ipv6-prefix": [
                
        ],
        "ipv6-prefix-assignment": [
                
        ],
        "route": [
                {
                        "target": "2604:5500:f:11::",
                        "mask": 64,
                        "nexthop": "::",
                        "metric": 256,
                        "valid": 2591913,
                        "source": "::\/0"
                },
                {
                        "target": "2604:5500:4::",
                        "mask": 56,
                        "nexthop": "::",
                        "metric": 256,
                        "valid": 2591913,
                        "source": "::\/0"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::768e:f8ff:fea6:7ec1",
                        "metric": 1024,
                        "valid": 1713,
                        "source": "2604:5500:f:11:c24a:ff:fedd:53ba\/64"
                },
                {
                        "target": "::",
                        "mask": 0,
                        "nexthop": "fe80::768e:f8ff:fea6:7ec1",
                        "metric": 1024,
                        "valid": 1713,
                        "source": "::\/128"
                }
        ],
        "dns-server": [
                
        ],
        "dns-search": [
                
        ],
        "inactive": {
                "ipv4-address": [
                        
                ],
                "ipv6-address": [
                        
                ],
                "route": [
                        
                ],
                "dns-server": [
                        
                ],
                "dns-search": [
                        
                ]
        },
        "data": {
                
        }
}

Router advertisement received from ISP:

root@OpenWrt:/# tcpdump -i eth0.2 'ip6 && icmp6 && (ip6[40] = 134)' -vv
03:54:50.100461 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 96) fe80::768e:f8ff:fea6:7ec1 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 96
        hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
          source link-address option (1), length 8 (1): 74:8e:f8:a6:7e:c1
            0x0000:  748e f8a6 7ec1
          mtu option (5), length 8 (1):  1500
            0x0000:  0000 0000 05dc
          prefix info option (3), length 32 (4): 2604:5500:4::/56, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
            0x0000:  38c0 0027 8d00 0009 3a80 0000 0000 2604
            0x0010:  5500 0004 0000 0000 0000 0000 0000
          prefix info option (3), length 32 (4): 2604:5500:f:11::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
            0x0000:  40c0 0027 8d00 0009 3a80 0000 0000 2604
            0x0010:  5500 000f 0011 0000 0000 0000 0000

Downstream equipment only receives link-local address.

Router advertisement received by downstream node.

21:10:07.866988 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 136) fe80::c24a:ff:fedd:53ba > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 136
	hop limit 0, Flags [managed, other stateful], pref medium, router lifetime 0s, reachable time 0s, retrans time 0s
	  source link-address option (1), length 8 (1): c0:4a:00:dd:53:ba
	  mtu option (5), length 8 (1):  1500
	  prefix info option (3), length 32 (4): fd1d:a3a3:e9a0::/64, Flags [onlink, auto], valid time 7200s, pref. time 1800s
	  unknown option (24), length 24 (3): 
	  0x0000:  3000 0000 1c20 fd1d a3a3 e9a0 0000 0000
	  0x0010:  0000 0000 0000

Why is the /56 prefix not used?

[cyrus]

Replying to neutronscott:

odhcp6c must send a router solicitation, because I receive 1 RA which has a lifetime of 1800s. Either my ISP or my modem doesn't send RAs without a RS. So 30min later I have no default routes. "ip -6 route show" doesn't show this timeout for the routes, though it's exactly 30min later every time and that's the router lifetime in the RA.

Sounds like a bug with your modem / ISP.

1. change accept_ra=2 in /proc/sys/net/ipv6/conf/all to override the default behaviour of turning off solicitations
2. have odhcp6c add the default route indefinitely
3. have odhcp6c send the RS

The problem here is that you must not send any solicitations after you've received the first RS. This is specified behavior and I don't really want to violate this in the default settings. Setting the router indefinitely isn't a good idea either.

I just commited a small change which may or may not help in your case. RSs are now sent with included source link-layer address option which is optional but it seems most clients do this and maybe your modem / ISP somehow expects this / uses this to send regular RAs.

[cyrus]

Replying to erik@…:

Why is the /56 prefix not used?

Because that prefix isn't delegated to you but is announced as belonging to the interface where the RA is sent which means you cannot simply take it and assign it (or parts of it somewhere else).

Your ISP needs to use DHCPv6-PD to delegate the /56 but not RAs.
What company is this anyway?

[neutronscott]

Hmm. I don't recv ANY ip6-multicast, only ether broadcast.

The RFC says unsolicited RAs are sent on multicast capable links, which perhaps mine is not. DOCSIS seems to provide methods for allowing multicast (which is vendor proprietary and likely the bug here).

But radvd also allows a UnicastOnly option. How would that be dealt with? The RFC isn't clear.

[johnllyon@…]

Original bug submitter here with a little more background information.

I've tested (a long time ago) IPv6 functionality on my internet connection. Plugging a single computer (e.g. laptop) into the cable modem (DOCSIS 3.0) gets my computer a functioning IPv6 connection. The machine was running Windows 7 Professional. However, with the router plugged in, I get partial IPv6 connectivity at best. Although I can resolve AAAA DNS records, I can't ping IPv6 addresses. Computers behind the router only have link-local connectivity as best I can tell.

This tells me a few things. 1) My ISP provides a functional native IPv6 connection. 2) Windows 7's implementation is doing something that Barrier Breaker is not.

What I need to do is two things. First, I need to install tomorrow's snapshot and see if Cyrus's small change fixed my problem. If it does, then great! If it does not, then I need to unhook the router and hook my laptop back up to the cable modem and sniff the traffic to see what the laptop does differently from OpenWRT. That is unlikely to happen until this weekend due to real life factors.

[neutronscott]

Replying to johnllyon@…:

Original bug submitter here with a little more background information.

I thought my issue may have been the same, since I don't see any ip6 traffic leaving your wan and no routes.

Could you do a dump as the interface is coming up?

ifdown wan6
{ sleep 5; ifup wan6; } & tcpdump -i eth1 -w tcpdump.out ip6

[anonymous]

Replying to johnllyon@…:

Original bug submitter here with a little more background information.

I've tested (a long time ago) IPv6 functionality on my internet connection. Plugging a single computer (e.g. laptop) into the cable modem (DOCSIS 3.0) gets my computer a functioning IPv6 connection. The machine was running Windows 7 Professional. However, with the router plugged in, I get partial IPv6 connectivity at best. Although I can resolve AAAA DNS records, I can't ping IPv6 addresses. Computers behind the router only have link-local connectivity as best I can tell.

That's exactly what I just tested. I rebooted the modem and plugged in a Win7 computer directly. I got a good IPv6 address (2001::xx) and I could actually connect to IPv6 websites. Rebooted the modem and plugged my OpenWRT router back in. I do get good IPv6 addresses (2001::xx on the WAN and 2601::xx on the LAN). My internal network is fine, and I can even ping the IPv6 address of the WAN. But no further.

[apple4ever]

Sleep and bring up eth1

[apple4ever]

(That was me two posts ago).

neutronscott: tcpdump 3 is the result of running your command for you.

I also noticed that I get an "operation not permitted" when I try to ping6 Facebook.com until I add a route manually to eth1

[johnllyon@…]

This is the first of several posts. I'm keeping them separate to aid clarity and organization.

So I installed the latest snapshot, which should incorporate Cyrus's changes. I now get a different error. Instead of the message "ping6: sendto: Operation not permitted," I get the following:

root@OpenWrt:/etc/config# ping6 www.google.com
PING www.google.com (2607:f8b0:4009:803::1011): 56 data bytes
^C
--- www.google.com ping statistics ---
157 packets transmitted, 0 packets received, 100% packet loss

So, I can resolve the AAAA record for google.com, and the ping command attempts to send IPv6 ICMP packets out, but all of them die. I have no idea at this point whether the problem is with my ISP or with OpenWRT, but I will investigate further.

[johnllyon@…]

TCPDump of WAN IP6 Traffic as WAN Comes Up

[johnllyon@…]

Replying to neutronscott:

Replying to johnllyon@…:

Original bug submitter here with a little more background information.

I thought my issue may have been the same, since I don't see any ip6 traffic leaving your wan and no routes.

Could you do a dump as the interface is coming up?

ifdown wan6
{ sleep 5; ifup wan6; } & tcpdump -i eth1 -w tcpdump.out ip6

Done. See TCPDump4.out using the latest version of OpenWRT. Note that now I do get a different error when using ping6, but all packets still timeout.

[erik@…]

Replying to cyrus:

Replying to erik@…:
Your ISP needs to use DHCPv6-PD to delegate the /56 but not RAs.

I checked with tcpdump. My ISP does not respond to DHCPv6.

The IPv6 documentation needs to be updated on openwrt.org. Can I help with this? It would be great to have a troubleshooting guide to catch stuff like this.

What company is this anyway?

This is Webpass in San Francisco. They offer service through a ethernet jack in your apartment.

They're great, but they've stopped giving customers public IPs. All customer IPv4 traffic will be NATed because they are out of IPs.

[anonymous]

Replying to erik@…:

Replying to cyrus:

Replying to erik@…:
Your ISP needs to use DHCPv6-PD to delegate the /56 but not RAs.

I checked with tcpdump. My ISP does not respond to DHCPv6.

The IPv6 documentation needs to be updated on openwrt.org. Can I help with this? It would be great to have a troubleshooting guide to catch stuff like this.

What company is this anyway?

This is Webpass in San Francisco. They offer service through a ethernet jack in your apartment.

They're great, but they've stopped giving customers public IPs. All customer IPv4 traffic will be NATed because they are out of IPs.

This is covered, it's just the documentation has various pages covering the same topic and one often is bad... Try relaying:

​http://wiki.openwrt.org/doc/uci/network6#router.advertisement.dhcpv6

[johnllyon@…]

This ticket should be marked as closed or resolved. The cause of this error message was due to a misconfiguration in the /etc/config/dhcp6c file. I had the enabled option on the first line set to "0" instead of "1." Making this change solved my problem. I can't believe I made such a simple error, but it's easy to miss using the LUCI interface, and sometimes when editing a text config file, you skip to the parts you care about without analyzing the default settings.

A more technical explanation is that because dhcp6c was not enabled, ipv6 utilities could not make an ipv6 connection. Similarly, ipv6 addresses were not being properly handed out. Now, I run the ping6 and traceroute6 utilities. Although these utilities timeout when trying to reach anything outside my network, they work fine internally. So that is a different issue (probably configuration related).

I hope this helps.

[apple4ever]

Replying to johnllyon@…:

This ticket should be marked as closed or resolved. The cause of this error message was due to a misconfiguration in the /etc/config/dhcp6c file. I had the enabled option on the first line set to "0" instead of "1." Making this change solved my problem. I can't believe I made such a simple error, but it's easy to miss using the LUCI interface, and sometimes when editing a text config file, you skip to the parts you care about without analyzing the default settings.

A more technical explanation is that because dhcp6c was not enabled, ipv6 utilities could not make an ipv6 connection. Similarly, ipv6 addresses were not being properly handed out. Now, I run the ping6 and traceroute6 utilities. Although these utilities timeout when trying to reach anything outside my network, they work fine internally. So that is a different issue (probably configuration related).

I hope this helps.

Isn't whole point of this ticket is that outside IPv6 connections aren't working? That's clearly in your original ticket description. Internal IPv6 connections have always worked for me- but I cannot ping or connect to external IPv6 addresses.

So I vote to keep this ticket open.

[johnllyon@…]

This bug came back with Barrier Breaker RC2. My WAN and LAN interfaces are receiving the correct ipv6 addresses from my ISP. At first after upgrading, all attempts to ping google (ping6 www.google.com) timed out. However, after a few hours I get the original error message of

root@OpenWrt:~# ping6 www.google.com
PING www.google.com (2607:f8b0:4002:c06::69): 56 data bytes
ping6: sendto: Operation not permitted

I'm not sure what is going on, but I suspect there's a setting mismatch between what Barrier Breaker's default settings are and what is required to work with my ISP (Comcast).

[cyrus]

Did you actually try to use the RC2 with default settings (i.e. don't keep old settings / reset to factory defaults). I suspect there are some old settings lingering around that do something bad. I also saw you mentioning dhcp6c and its config file. We don't use that by default for well over a year in trunk / BB.

[johnllyon@…]

Haha! It WORKS!!! The config file settings changed at some point. Resetting the firmware to default and clearing everything cured it all.

I suspect that's been the problem for me the entire time.

[apple4ever]

I was starting to think it might be related to that- but of course that's a big job because I have a lot setup on my router. Guess I'll give it a shot tonight and see what happens.

[den.de]

I think i am effected by the same bug. I am using OpenWRT on my TP-Link 841ND and was willing to get ipv6 to work. My computers do get a valid ipv6 adress as far as i can see, but i am not able to open ipv6 sites and ipv6 tests fail.

I tried the default settings on my router with BB rc1, rc2 and latest trunk, but it did not work. I even tried it with another router, TP-Link 4300. On both routers i see the same result.

i can't even ping from the router...

root@OpenWrt:/# ping6 ipv6.google.com
PING ipv6.google.com (2a00:1450:400f:802::100e): 56 data bytes
ping6: sendto: Operation not permitted

I got DOCSIS involved on my side, JFYI..

[cyrus]

@den.de Any more information on your side? Output of ifstatus wan6? If possible tcpdump of the RA & DHCPv6-exhange. See ​https://dev.openwrt.org/ticket/16781#comment:8 as a very good example.

[apple4ever]

I wiped my router and IPv6 works now! Woohoo! Guess I shouldn't have put it off for so long, but hopefully others who find this will know what do to.

[den.de]

So i am back from my holidays and back on it.
First of all i tried to reset my router, then upgraded to BBrc3, after this i tried the latest trunk.
It just did not work. I tried each build with the standard settings, everytime the same result.

root@OpenWrt:/# ping6 ipv6.google.com
PING ipv6.google.com (2a00:1450:400f:802::100e): 56 data bytes
ping6: sendto: Operation not permitted

on my laptop it says the following: (despite the computer has a valid ipv6 adress from the router)

den.de@maboo ~ $> ping6 google.com
ping6: UDP connect: No route to host

the output of ifstatus is the following:

root@OpenWrt:/etc# ifstatus wan6
{
        "up": true,
        "pending": false,
        "available": true,
        "autostart": true,
        "uptime": 4296,
        "l3_device": "eth1",
        "proto": "dhcpv6",
        "device": "eth1",
        "updated": [
                "addresses",
                "prefixes",
                "data"
        ],
        "metric": 0,
        "delegation": true,
        "ipv4-address": [
                
        ],
        "ipv6-address": [
                {
                        "address": "2a00:c1a0:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx",
                        "mask": 128,
                        "preferred": 1205304,
                        "valid": 1205304
                }
        ],
        "ipv6-prefix": [
                {
                        "address": "2a00:c1a0:xxxx:xxxx::",
                        "mask": 56,
                        "preferred": 1205304,
                        "valid": 1205304,
                        "class": "wan6",
                        "assigned": {
                                "lan": {
                                        "address": "2a00:c1a0:xxxx:xxxx::",
                                        "mask": 60
                                }
                        }
                }
        ],
        "ipv6-prefix-assignment": [
                
        ],
        "route": [
                
        ],
        "dns-server": [
                "2a00:c1a0:0:800:217:68:161:141",
                "2a00:c1a0:0:801:217:68:161:171"
        ],
        "dns-search": [
                "primacom.net"
        ],
        "inactive": {
                "ipv4-address": [
                        
                ],
                "ipv6-address": [
                        
                ],
                "route": [
                        
                ],
                "dns-server": [
                        
                ],
                "dns-search": [
                        
                ]
        },
        "data": {
                "passthru": "001700202a00c1a00000080002170068016101412a00c1a0000008010217006801610171"
        }
}

More Information: my ISP is working with Dualstack.
And i got a tcpdump but didnt figure out yet how to upload it here :/

den.de

[den.de]

i hope this helps.

[cyrus]

@den.de the problem doesn't seem to be caused by OpenWrt. The reason you can't connect is that your ISP does DHCPv6 but does not send Router Advertisements. However DHCPv6 cannot be used to announce a default router thus OpenWrt doesn't know where to send packages to. You can see OpenWrt sending Router Solicitations to request Router Advertisements but the ISP not answering them.

I guess you should send an email to your ISP and tell them that so they can fix or enable Router Advertisements for you then all should be good.

[stephan@…]

Is there anything an end user can do to get this to work? Or is this strictly a head-end thing for the ISP?

[mahadir@…]

I also have this problem before (ping: sendto: Operation not permitted) but for my case the IPv6 was not from the ISP instead from TSP tunneling (gw6c). I managed to solve it by installing router advertisement daemon (radvd). If somehow the radvd is not included in your default repository. Can manually install it by ssh/telnet to the router and issue the following commands.

# wget ​http://sourceforge.net/projects/orwrt/files/0.70/packages/radvd_1.9.1-1_ar71xx.ipk/download -O radvd_1.9.1-1_ar71xx.ipk

# opkg install radvd_1.9.1-1_ar71xx.ipk

[anonymous]

radvd is not needed as OpenWrt comes with its own replacement. See ​http://wiki.openwrt.org/doc/uci/network6#router.advertisement.dhcpv6 for configuration.

[amp@…]

I think I have this exact problem. I will upload a tcpdump below. The most direct symptom is:

root@OpenWrt:~# wget ipv6.google.com
Connecting to ipv6.google.com ([2607:f8b0:4000:804::1005]:80)
wget: can't connect to remote host: Operation not permitted

There are no routes being added for ipv6. However the tcpdump (based on my limited understanding) shows a router advertising. So I don't know why it's not working. I tried manually adding a route to the router that sent the advertisement packets, but it didn't work. With the route in place I get a different error though:

root@OpenWrt:~# wget ipv6.google.com
Connecting to ipv6.google.com ([2607:f8b0:4000:804::1003]:80)
wget: can't connect to remote host: No route to host

root@OpenWrt:~# ifstatus wan6
{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"uptime": 10,
	"l3_device": "eth1",
	"proto": "dhcpv6",
	"device": "eth1",
	"updated": [
		"addresses",
		"prefixes"
	],
	"metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		{
			"address": "2605:6000:ffc0:64:4021:417:9f11:24fa",
			"mask": 128,
			"preferred": 599470,
			"valid": 599470
		}
	],
	"ipv6-prefix": [
		{
			"address": "2605:6000:1019:106::",
			"mask": 64,
			"preferred": 599470,
			"valid": 599470,
			"class": "wan6",
			"assigned": {
				"lan": {
					"address": "2605:6000:1019:106::",
					"mask": 64
				}
			}
		}
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		
	],
	"dns-server": [
		
	],
	"dns-search": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		]
	},
	"data": {
		
	}
}

[amp@…]

TCP Dump showing DHCPv6 and RA communication

[amp@…]

And through this entire process the LuCI UI shows IPv6 WAN Status as Not connected.

[amp@…]

I have successfully fixed the problem. The fix is described here: ​https://forum.openwrt.org/viewtopic.php?pid=233790#p233790

RA packets where being blocked by the OpenWRT firewall.

It looks to me like either an incorrect configuration is included in the image I used (​https://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/openwrt-ar71xx-generic-wzr-hp-g300nh-squashfs-sysupgrade.bin), or my old firewall config was kept form the old release. The latter is more likely since I do have custom firewall rules in there. A clean install may well not have had this problem.

[anonymous]

@amp this does not fix it for me. still not working with the latest trunk on TP-Link 3600.