#16781 closed defect (worksforme)
Native IPv6 Not Working on Barrier Breaker
Reported by: | johnllyon@… | Owned by: | cyrus |
---|---|---|---|
Priority: | high | Milestone: | Chaos Calmer 15.05 |
Component: | packages | Version: | Trunk |
Keywords: | Cc: | cyrus@… |
Description
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.
Attachments (6)
Change History (44)
comment:1 Changed 4 years ago by anonymous
comment:2 Changed 4 years ago by cyrus
- Owner changed from developers to cyrus
- Status changed from new to accepted
comment:3 Changed 4 years ago by cyrus
- Cc cyrus@… added
comment:4 Changed 4 years ago by 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!
comment:5 Changed 4 years ago by 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.
comment:6 Changed 4 years ago by 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": { } }
comment:7 follow-up: ↓ 9 Changed 4 years ago by 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)
- change accept_ra=2 in /proc/sys/net/ipv6/conf/all to override the default behaviour of turning off solicitations
- have odhcp6c add the default route indefinitely
- have odhcp6c send the RS
comment:8 follow-up: ↓ 10 Changed 4 years ago by 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?
comment:9 in reply to: ↑ 7 Changed 4 years ago by 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.
- change accept_ra=2 in /proc/sys/net/ipv6/conf/all to override the default behaviour of turning off solicitations
- have odhcp6c add the default route indefinitely
- 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.
comment:10 in reply to: ↑ 8 ; follow-up: ↓ 18 Changed 4 years ago by 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?
comment:11 Changed 4 years ago by 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.
comment:12 follow-ups: ↓ 13 ↓ 14 Changed 4 years ago by 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.
comment:13 in reply to: ↑ 12 ; follow-up: ↓ 17 Changed 4 years ago by 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
comment:14 in reply to: ↑ 12 Changed 4 years ago by 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.
comment:15 Changed 4 years ago by 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
comment:16 Changed 4 years ago by 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.
comment:17 in reply to: ↑ 13 Changed 4 years ago by 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.
comment:18 in reply to: ↑ 10 ; follow-up: ↓ 19 Changed 4 years ago by 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.
comment:19 in reply to: ↑ 18 Changed 4 years ago by 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
comment:20 follow-up: ↓ 21 Changed 4 years ago by 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.
comment:21 in reply to: ↑ 20 Changed 4 years ago by 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.
comment:22 Changed 4 years ago by 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).
comment:23 Changed 4 years ago by 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.
comment:24 Changed 4 years ago by 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.
comment:25 Changed 4 years ago by 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.
comment:26 Changed 4 years ago by 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..
comment:27 Changed 4 years ago by 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.
comment:28 Changed 4 years ago by 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.
comment:29 Changed 4 years ago by cyrus
- Resolution set to fixed
- Status changed from accepted to closed
comment:30 Changed 3 years ago by den.de
- Resolution fixed deleted
- Status changed from closed to reopened
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
comment:31 Changed 3 years ago by cyrus
- Resolution set to worksforme
- Status changed from reopened to closed
@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.
comment:32 Changed 3 years ago by 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?
comment:33 Changed 3 years ago by 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
comment:34 Changed 3 years ago by 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.
comment:35 Changed 3 years ago by 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": { } }
comment:36 Changed 3 years ago by amp@…
And through this entire process the LuCI UI shows IPv6 WAN Status as Not connected.
comment:37 Changed 3 years ago by 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.
comment:38 Changed 3 years ago by anonymous
@amp this does not fix it for me. still not working with the latest trunk on TP-Link 3600.
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.