OpenWrt IPv6 issue?

I have an odd problem with IPv6. It appears to be common to OpenWrt 18.06.8 and 19.07.4, and Inteno IOPSYS which is OpenWrt based.

On a freshly powered-up router, I can run ping -6 on my laptop to remote destinations the other side of the router with no problems.
However, if I physically disconnect the WAN Ethernet cable so the interface drops, then reconnect, the WAN6 interface comes up (eventually) but IPv6 behaves oddly. Ping -6 to the remote destinations works for a while (roughly a minute or so), then stops working with destination unreachable error messages for a minute or so, then starts working again, then not, with no regular operation/no-operation pattern or time interval. Web browsers that try to use IPv6 have problems.
Restarting the WAN6 interface does not resolve the problem, but power-cycling the router does.
On OpenWrt 18.06.8 collectd ping doesn't parse IPv6 addresses, but collectd ping does work for IPv6 addresses on 19.07.4: and pinging from the router shows the same behaviour - it is not a PC artefact, or local networking issue. Using the statistics package to graph the IPv6 pings shows a packet loss rate of about 45%.
Is this something anyone else has experienced/resolved? Any ideas what it might be? I have tried three different routers (TP-Link Archer C7 v2, TP-Link Archer C7 v4, Inteno something or other), and have the same symptoms, so it isn't the router hardware.
My next step is to bypass the router and simply put a Linux PC directly attached to the WAN Ethernet, but I don't know when I can try that. If anyone recognises this problem and knows the resolution, please reply!

Also check if any those helps or not:

ifup wan6; ifup lan
/etc/init.d/odhcpd restart

Compare before and after the issue happens:

ifstatus wan6; ifstatus lan
ip -6 address show; ip -6 route show table all; \
ip -6 rule show; ip6tables-save

This sounds similar to this bug:

It seems to affect many ath79 devices making them, well, less useful than they should be.... but as far as I can tell, no work has been done to fix it. I think it is the ethernet driver.

If this is the issue here then you can work around it by configuring a lan port for wan use, but then you loose a port.

1 Like

I don't think so, as I don't see the WAN interface restarting. Thank-you for the suggestion, though.

Thank you for the suggestions. I'm trying to make the problem reproducible at the moment. I have a GigE from my ISP which terminates in a 'breakout box' with four GigE interfaces on it, which appear to be switched i.e. Wireshark on one interface doesn't see traffic over another interface..
I have up to three routers connected, each to its own GigE interface:

  • a TP-Link Archer C7 v2 running OpenWrt 18.06.8
  • a TP-Link Archer C7 v4 running 19.07.4
  • an Inteno EX400 running EX400-X-INT-4.1.6-190404_1753 kernel 4.4.14 ( IOPSYS is OpenWrt based)

I do not have root or command line access on the Inteno, as it is supplied by the ISP.

On all three routers, IPv4 is rock solid.

On all three router IPv6 is unstable. Pinging remote IPv6 devices I get packet loss up to 80-odd per-cent, and network timeouts. It plays merry hell with the 'Happy Eyeballs' implementation in Firefox, as IPv6 can appear to be working, then time out for extended periods before returning.

The upstream ISP device has a Huawei MAC address.

I have adequate understanding of IPv4, but I am not expert on the niceties of IPv6 setup and routing.

After an interface restart, it can take 10-20 minutes before the WAN6 interface comes up and gets IPv6 addresses.

I can run Wireshark on a PC, but I don't currently have access to a switch with mirroring capability. I can add mirroring on the TP-Link Archer C7 v4, but I'm not sure of the config to stop it trying to interfere and route when all I want is a switch with LAN1 connected to the upstream WAN, LAN2 as the mirror port of LAN1 and LAN2 connected to the downstream router. I may well shell out for a TP-Link TL-SG108E switch just to make things easy (and I can find a use for it later).

I'm also getting instances of the "ping: sendto: Permission denied" error (documented elsewhere in this forum), so something is not working well.

https://unix.stackexchange.com/questions/581753/what-is-ping6-sendto-permission-denied-a-sign-of-when-debugging

https://forum.openwrt.org/t/ping6-sendto-permission-denied-on-some-ipv6-addresses/61163

Essential, the TP-Link Archer C7 v4 running 19.07.4 is the 'crash test dummy', and available for weird and wonderful configs and can be rebooted without problems. The Inteno is ISP supplied and locked down, but experiences the same IPv6 issues, and the Archer C7 v2 running 18.06.8 is the production router that I'd prefer not to mess with until I have a better working config. It has IPv6 issues too.

I put a notebook PC running Linux directly attached to the ISP breakout and captured interface startup and pinging the problematic destinations from the PC with Wireshark, but could see no obvious problems. It seems to be a specific issue with OpenWrt, or possibly a specific combination of OpenWrt and Huawei: if this were a general problem, more people than me would be tearing their hair out in frustration. I want to get IPv6 working reliably.

I did a power-off->power-on restart of the OpenWrt 19.07.04 router while composing this posting. IPv4 is up. The WAN6 interface is stubbornly still down after seventeen (17) came up after 35 (thirty-five) minutes.

Edit to Add:

Sun Oct 25 21:37:13 2020 kern.notice kernel: [    0.000000] Linux version 4.14.195 (builder@buildhost) (gcc version 7.5.0 (OpenWrt GCC 7.5.0 r11208-ce6496d796)) #0 Sun Sep 6 16:19:39 2020
...
Sun Oct 25 22:12:57 2020 daemon.notice netifd: Interface 'wan6' is now up

...and while perusing the kernel log, I saw this. Hmm.
Sun Oct 25 22:12:58 2020 daemon.warn odhcpd[1244]: A default route is present but there is no public prefix on lan thus we don't announce a default route!

While interface down:

# ifstatus wan6
{
	"up": false,
	"pending": true,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"proto": "dhcpv6",
	"device": "eth0.2",
	"data": {
		
	}
}
# ifstatus lan
{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 941,
	"l3_device": "br-lan",
	"proto": "static",
	"device": "br-lan",
	"updated": [
		"addresses"
	],
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		{
			"address": "192.168.8.1",
			"mask": 24
		}
	],
	"ipv6-address": [
		
	],
	"ipv6-prefix": [
		
	],
	"ipv6-prefix-assignment": [
		{
			"address": "fdb6:1bed:70ff::",
			"mask": 60,
			"local-address": {
				"address": "fdb6:1bed:70ff::1",
				"mask": 60
			}
		}
	],
	"route": [
		
	],
	"dns-server": [
		
	],
	"dns-search": [
		
	],
	"neighbors": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		],
		"neighbors": [
			
		]
	},
	"data": {
		
	}
}
# ip -6 address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::724f:57ff:fe8a:755c/64 scope link 
       valid_lft forever preferred_lft forever
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fdb6:1bed:70ff::1/60 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::724f:57ff:fe8a:755c/64 scope link 
       valid_lft forever preferred_lft forever
8: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::724f:57ff:fe8a:755d/64 scope link 
       valid_lft forever preferred_lft forever
9: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::724f:57ff:fe8a:755b/64 scope link 
       valid_lft forever preferred_lft forever
10: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::724f:57ff:fe8a:755c/64 scope link 
       valid_lft forever preferred_lft forever
# ip -6 route show table all
fdb6:1bed:70ff::/64 dev br-lan  metric 1024 
unreachable fdb6:1bed:70ff::/48 dev lo  metric 2147483647  error -148
fe80::/64 dev eth0  metric 256 
fe80::/64 dev eth0.2  metric 256 
fe80::/64 dev br-lan  metric 256 
fe80::/64 dev wlan1  metric 256 
fe80::/64 dev wlan0  metric 256 
local ::1 dev lo table local  metric 0 
anycast fdb6:1bed:70ff:: dev br-lan table local  metric 0 
local fdb6:1bed:70ff::1 dev br-lan table local  metric 0 
anycast fe80:: dev eth0.2 table local  metric 0 
anycast fe80:: dev eth0 table local  metric 0 
anycast fe80:: dev br-lan table local  metric 0 
anycast fe80:: dev wlan1 table local  metric 0 
anycast fe80:: dev wlan0 table local  metric 0 
local fe80::724f:57ff:fe8a:755b dev wlan0 table local  metric 0 
local fe80::724f:57ff:fe8a:755c dev eth0 table local  metric 0 
local fe80::724f:57ff:fe8a:755c dev br-lan table local  metric 0 
local fe80::724f:57ff:fe8a:755c dev wlan1 table local  metric 0 
local fe80::724f:57ff:fe8a:755d dev eth0.2 table local  metric 0 
ff00::/8 dev eth0 table local  metric 256 
ff00::/8 dev br-lan table local  metric 256 
ff00::/8 dev eth0.2 table local  metric 256 
ff00::/8 dev wlan1 table local  metric 256 
ff00::/8 dev wlan0 table local  metric 256
# ip -6 neigh show
fe80::30ae:8087:841d:c540 dev br-lan lladdr b8:86:87:5f:42:eb used 0/0/0 probes 4 STALE
fe80::ded2:fcff:fe03:782d dev eth0.2 lladdr dc:d2:fc:03:78:2d router ref 1 used 0/0/0 probes 1 REACHABLE
fe80::724f:57ff:fe8a:755d dev eth0.2 lladdr 70:4f:57:8a:75:5d used 0/0/0 probes 0 STALE</code>
<code># ip -6 rule show
0:	from all lookup local 
32766:	from all lookup main 
4200000001:	from all iif lo lookup unspec 12
4200000006:	from all iif br-lan lookup unspec 12
4200000008:	from all iif eth0.2 lookup unspec 12

After interface came up:

# ifstatus wan6
{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 488,
	"l3_device": "eth0.2",
	"proto": "dhcpv6",
	"device": "eth0.2",
	"updated": [
		"addresses",
		"routes",
		"prefixes",
		"data"
	],
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		
	],
	"ipv6-address": [
		{
			"address": "2a0a:2780:4fff:1dd8:b514:567b:2a52:30d0",
			"mask": 128,
			"preferred": 1752,
			"valid": 3102
		}
	],
	"ipv6-prefix": [
		{
			"address": "2a0a:2780:4f4c::",
			"mask": 48,
			"preferred": 1752,
			"valid": 3102,
			"class": "wan6",
			"assigned": {
				"lan": {
					"address": "2a0a:2780:4f4c::",
					"mask": 60
				},
				"wireless": {
					"address": "2a0a:2780:4f4c:10::",
					"mask": 60
				}
			}
		}
	],
	"ipv6-prefix-assignment": [
		
	],
	"route": [
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::ded2:fcff:fe03:782d",
			"metric": 512,
			"valid": 814,
			"source": "2a0a:2780:4f4c::/48"
		},
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::ded2:fcff:fe03:782d",
			"metric": 512,
			"valid": 814,
			"source": "2a0a:2780:4fff:1dd8:b514:567b:2a52:30d0/128"
		}
	],
	"dns-server": [
		"2a0a:2780:2::2",
		"2001:4860:4860::8888"
	],
	"dns-search": [
		
	],
	"neighbors": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		],
		"neighbors": [
			
		]
	},
	"data": {
		"passthru": "001700202a0a278000020000000000000000000220014860486000000000000000008888"
	}
}
# ifstatus lan
{
	"up": true,
	"pending": false,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"uptime": 2284,
	"l3_device": "br-lan",
	"proto": "static",
	"device": "br-lan",
	"updated": [
		"addresses"
	],
	"metric": 0,
	"dns_metric": 0,
	"delegation": true,
	"ipv4-address": [
		{
			"address": "192.168.8.1",
			"mask": 24
		}
	],
	"ipv6-address": [
		
	],
	"ipv6-prefix": [
		
	],
	"ipv6-prefix-assignment": [
		{
			"address": "2a0a:2780:4f4c::",
			"mask": 60,
			"preferred": 1667,
			"valid": 3017,
			"local-address": {
				"address": "2a0a:2780:4f4c::1",
				"mask": 60
			}
		},
		{
			"address": "fdb6:1bed:70ff::",
			"mask": 60,
			"local-address": {
				"address": "fdb6:1bed:70ff::1",
				"mask": 60
			}
		}
	],
	"route": [
		
	],
	"dns-server": [
		
	],
	"dns-search": [
		
	],
	"neighbors": [
		
	],
	"inactive": {
		"ipv4-address": [
			
		],
		"ipv6-address": [
			
		],
		"route": [
			
		],
		"dns-server": [
			
		],
		"dns-search": [
			
		],
		"neighbors": [
			
		]
	},
	"data": {
		
	}
}
# ip -6 address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::724f:57ff:fe8a:755c/64 scope link 
       valid_lft forever preferred_lft forever
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a0a:2780:4f4c::1/60 scope global dynamic 
       valid_lft 2941sec preferred_lft 1591sec
    inet6 fdb6:1bed:70ff::1/60 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::724f:57ff:fe8a:755c/64 scope link 
       valid_lft forever preferred_lft forever
8: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a0a:2780:4fff:1dd8:b514:567b:2a52:30d0/128 scope global dynamic 
       valid_lft 2941sec preferred_lft 1591sec
    inet6 fe80::724f:57ff:fe8a:755d/64 scope link 
       valid_lft forever preferred_lft forever
9: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::724f:57ff:fe8a:755b/64 scope link 
       valid_lft forever preferred_lft forever
10: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::724f:57ff:fe8a:755c/64 scope link 
       valid_lft forever preferred_lft forever
# ip -6 route show table all
default from 2a0a:2780:4f4c::/48 via fe80::ded2:fcff:fe03:782d dev eth0.2  metric 512 
default from 2a0a:2780:4fff:1dd8:b514:567b:2a52:30d0 via fe80::ded2:fcff:fe03:782d dev eth0.2  metric 512 
2a0a:2780:4f4c::/64 dev br-lan  metric 1024 
unreachable 2a0a:2780:4f4c::/48 dev lo  metric 2147483647  error -148
fdb6:1bed:70ff::/64 dev br-lan  metric 1024 
unreachable fdb6:1bed:70ff::/48 dev lo  metric 2147483647  error -148
fe80::/64 dev eth0  metric 256 
fe80::/64 dev eth0.2  metric 256 
fe80::/64 dev br-lan  metric 256 
fe80::/64 dev wlan1  metric 256 
fe80::/64 dev wlan0  metric 256 
local ::1 dev lo table local  metric 0 
anycast 2a0a:2780:4f4c:: dev br-lan table local  metric 0 
local 2a0a:2780:4f4c::1 dev br-lan table local  metric 0 
local 2a0a:2780:4fff:1dd8:b514:567b:2a52:30d0 dev eth0.2 table local  metric 0 
anycast fdb6:1bed:70ff:: dev br-lan table local  metric 0 
local fdb6:1bed:70ff::1 dev br-lan table local  metric 0 
anycast fe80:: dev eth0.2 table local  metric 0 
anycast fe80:: dev eth0 table local  metric 0 
anycast fe80:: dev br-lan table local  metric 0 
anycast fe80:: dev wlan1 table local  metric 0 
anycast fe80:: dev wlan0 table local  metric 0 
local fe80::724f:57ff:fe8a:755b dev wlan0 table local  metric 0 
local fe80::724f:57ff:fe8a:755c dev eth0 table local  metric 0 
local fe80::724f:57ff:fe8a:755c dev br-lan table local  metric 0 
local fe80::724f:57ff:fe8a:755c dev wlan1 table local  metric 0 
local fe80::724f:57ff:fe8a:755d dev eth0.2 table local  metric 0 
ff00::/8 dev eth0 table local  metric 256 
ff00::/8 dev br-lan table local  metric 256 
ff00::/8 dev eth0.2 table local  metric 256 
ff00::/8 dev wlan1 table local  metric 256 
ff00::/8 dev wlan0 table local  metric 256
# ip -6 rule show
0:	from all lookup local 
32766:	from all lookup main 
4200000000:	from 2a0a:2780:4f4c::1/60 iif br-lan lookup unspec unreachable
4200000001:	from all iif lo lookup unspec 12
4200000006:	from all iif br-lan lookup unspec 12
4200000008:	from all iif eth0.2 lookup unspec 12
4200000008:	from all iif eth0.2 lookup unspec 12
1 Like

To add to the curious behaviour, I have noticed that if I run some continuous pings from a separate PC connected via the TP-Link Archer C7 v2 running OpenWrt 18.06.8, after a period, the pings fail with the message

From 2a0a:2780:4f1a::1 (2a0a:2780:4f1a::1) icmp_seq=10060 Destination unreachable: Address unreachable

(2a0a:2780:4f1a::1 is the IPv6 address of the br-lan interface to which the PC is attached on the OpenWrt router: in other words, the OpenWrt router is telling my PC the destination address is unreachable.)

However, if I log in to the router and ping a different [1] destination to the continuous pings set up from the PC, the PC pings start working again. This is entirely reproducible. After a while, the continuous pings give the Destination unreachable error, and a quick ping from the router itself gets things going again.
The continuous pings usually also restart of their own devices after an apparently random interval.

I feel a bit like Alice. Things are getting curiouser and curiouser.

I will, of course, see if the same behaviour occurs on OpenWrt 19.07.4

[1]it also works if I ping one of the destinations for which the continuous ping from the PC is failing.

1 Like

I'm suspecting your IPv6 firewall.

2 Likes

Well, I'm finding lots of new! exciting! ways to do packet captures and try and work out what is going on. The OpenWrt documentation came up trumps with this little gem:

https://openwrt.org/docs/guide-user/firewall/misc/tcpdump_wireshark

So I can configure the OpenWrt device to send the output from tcpdump to Wireshark running on a separate PC, so I can see what the WAN interface sees. You'll need to install tcpdump on the OpenWrt device.

To capture all packets on the WAN
(do NOT type the command line below in verbatim, it will need modifying for your own setup - it just illustrates the technique)

1. Enable SSH connection with certificate (to avoid password prompt)
2. On your GNU/Linux computer, or MacOsX:

ssh <user>@myopenwrtbox tcpdump -i eth1 -U -s0 -w - 'not port 22' | sudo wireshark -k -i -

(Actually, you can use password based authentication. I also recommend reading and understanding what all the options are and how this does its magic)

Similarly, once can use tcpdump on the OpenWrt device directly.

I've also come across ndpmon ( Neighbor Discovery Protocol Monitor (NDPMon) ) , and wondering if it could be packaged, or alternatively use the ssh technique with tcpdump to send packets to ndpmon running on a PC.

It currently looks (to my inexpert eye) like the upstream router is not responding to IPv6 ND Neighbor Solicitations sent by the OpenWrt device; and in addition, appears to send minimal Router Advertisements at infrequent intervals that seem to overrun the previous validity timeout. I need to dig and educate myself further. Sigh.

I reran a packet capture with the same result: the Archer C7 v4 running OpenWrt 19.07.4 sends IPv6 Neighbor Solicitations upstream through an ISP-controlled managed switch to a Huawei router. No Neighbor Advertisement comes back in reply.
The IPv6 neighbour table shows the IPv6 address of the link-local address of the upstream router, with status 'FAILED', with a probe count of 6, corresponding to the number of Neigbor solicitations sent: three to the router's unicast IPv6 address; and three to the multicast group.
As the Archer C7 has no neighbour relationship with the next-hop address for routing, it has nowhere to send packets. :frowning:
I am not confident I understand all the complexities of IPv6 Neighbour Discovery and Router Discovery/use, but it looks to me like the upstream Huawei code and the OpenWrt code either don't implement it properly, or don't agree on the implementation. Sigh. Again.
Hopefully the ISP has some insight.

1 Like

Well, nothing back from the ISP so far.
In the meantime, I've bought a TP-Link SG108Ev5 switch and captured the traffic between the ISP provided (Inteno) router and the ISPs Huawei edge equipment by port monitoring.

  1. The TP-Link SG108Ev5 switch sends out a lot of Realtek Remote Control Protocol Ethernet packets (Ethertype 0x8899), which is a tad irritating, and might be a security issue.
  2. Same symptoms as with OpenWrt router. Router comes up from power-on OK, but if you disconnect the WAN, wait for a reasonably long period, then reconnect it, IPv6 does not come up properly. It looks like the Huawei is ignoring IPv6 Neighbor Solicitations directed towards its Solicited Node Multicast Address. I shall have to read RFC 4861 ( Neighbor Discovery for IP version 6 (IPv6) ) carefully and maybe use the state diagram here: https://www.iol.unh.edu/sites/default/files/knowledgebase/ipv6/ND_statemachine.gif to see if I can work out if the Huawei/OpenWrt/IOPSYS are following the rules correctly. It could be that all have a flawed implementation. Sigh again. In the meantime IPv4 is working fine, so it is not a physical connectivity issue.
  3. Interesting to see some of the other traffic going on, such as the DNS query to stun.1.google.com

I believe I have this same problem on a Ubiquiti UniFi AP AC Lite which is also an ath79 device. It is running 19.7.6 and IPv6 behaves oddly similarly as described in the original post.

A newly connected smartphone will work just fine. After a while, IPv6 stops working correctly. IPv4 continues to work fine. Our current (annoying) workaround is to turn the smartphone's wifi off and on again.

Here's the same ~4 hour capture, where I am showing SYN and ACK packages. Top half is filtered to IPv4. These bahave as expected (syn being double that of ack is from my filter, that's fine):

Bottom half is filtered to IPv6.

It is easy to see how this tends to work for a while (red and green line being all squiggly) and then it breaking after a while (green line being there, but red is missing in most cases)

Whenever the ACKs do work, it was preceded by off-on workaround on that client device.

Here are my filters, in case you want to try the same:

  • not (ipv6) and tcp.flags.syn == 1
  • ipv6 && tcp.flags.syn == 1
  • ipv6 and tcp.flags.ack == 1 and tcp.flags.syn == 1
  • not (ipv6) and tcp.flags.ack == 1 and tcp.flags.syn == 1

(sorry for not ordering them better, but wireshark's IO graph didn't let me move them and I wanted to keep them in the same order as in the screenshot).

I just tested it on an ath79 device with 21.02-rc1, and it is still the same way.

Im on ath79 based as well the xiaomi mi 2350, can't get ipv6 to work either.