OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version openwrt-18.06
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 9
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Henry Gebhardt - 10.08.2018
Last edited by Felix Fietkau - 24.03.2019

FS#1763 - 18.06 doesn't obtain IPv6 address on mt76

OpenWRT-18.06 doesn’t obtain an IPv6 address on the wan6 interface since commit 424a9ae128bd2045cd4bfd6e3229f2529d150a25. IPv6 works before that commit. The git bisect output is

$ git bisect good
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
We cannot bisect more!

The WAN6 interface status when not working is

root@OpenWrt:~# ifstatus wan6
	"up": false,
	"pending": true,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"proto": "dhcpv6",
	"device": "eth0.2",
	"data": {		

The device is a Netgear R6220, and my ISP is Comcast in Pennsylvania.

I attach dmesg when running the last working commit.

Other users also have this problem, see this forum thread. (I’m the OP of that thread.)

Would be great to have IPv6 working again. Thank you!

Steps to reproduce:
0. Delete .config file, in “make menuconfig” select appropriate target (MediaTek Ralink MIPS), subtarget (MT7621), and target profile (Netgear R6220).
1a. Compile image prior to above commits, upload to router
1b. Run “sysupgrade -v -n /tmp/*.tar” 1c. Confirm that IPv6 is working, e.g. by pointing browser to, or “ifstatus wan6” on the router
2a. Compile image from source after above mentioned commits, e.g. tag “v18.06.0”, upload to router
2b. Run “sysupgrade -v -n /tmp/*.tar” 2c. Confirm that IPv6 is not working

   dmesg (17.8 KiB)
This task has the following sub-task
ID Project Summary Priority Severity Progress
1833 OpenWrt/LEDE Project  FS#1833 - No IPV6   Very Low Medium
Closed by  Felix Fietkau
24.03.2019 11:16
Reason for closing:  Fixed
Brian commented on 05.09.2018 16:15

Supply the following if possible:
- Device problem occurs on

  D-Link DIR-860L B1 AND TP-Link TL-WDR3600 V1.2

- Software versions of OpenWrt/LEDE release, packages, etc.


- Steps to reproduce

  Fresh install 18.06.1 with no configuration.
  Fresh install of works fine.

So it’s not just mt76 also ar71 and may be others. I am also a concast / xfinity customer so it may be related to them.

Henry Gebhardt commented on 06.09.2018 14:21

Brian wrote:
> So it’s not just mt76 also ar71 and may be others.

Hm, that might imply that something went wrong when I did "git bisect"? Would you be willing to bisect on the ar71, or at least verify my bisection result for mt76?

wiIIiam commented on 13.09.2018 16:51

I can confirm this issue exists on edgerouter-x running 18.06.1 (r7258) using Comcast. Tcpdump on wan interface (eth0.2) shows periodic dhcp6 solicit, without any response.

Dave Täht commented on 01.10.2018 15:29

I confirm this exists on comcast on an apu2 running 18.06.1 also. Sigh.

Dave Täht commented on 01.10.2018 16:14

I turned off ip6tables entirely, and took a packet cap. I see (on my hardware) a bad udp checksum... (but you would normally see that if you have checksum offloading enabled)

:/tmp# 09:12:17.404257 IP6 (flowlabel 0xdfff4, hlim 1, next-header UDP (17) payload length: 159) fe80::20d:b9ff:fe43:a06c.546 > ff02::1:2.547: [bad udp cksum 0x58f4 → 0xc4a1!]

Dave Täht commented on 01.10.2018 16:39

This arm box IS getting dhcpv6-pd correctly.

root@gw1:~# cat /etc/openwrt_release
DISTRIB_DESCRIPTION='OpenWrt 18.06.1 r7258-5eb055306f'

My mips and x86_64 boxes aren't

Tom commented on 10.10.2018 23:33

Still appears to be an issue on Ubiquiti Edgerouter ER-X (OpenWrt SNAPSHOT r8284-212aa33226). ISP is Spectrum (legacy Charter)

Jon Burgess commented on 22.10.2018 23:22

Did you try turning off the NET_MEDIATEK_OFFLOAD and NET_MEDIATEK_HW_QOS config options that the 424a9ae128bd patch added?

Tom commented on 23.10.2018 22:57

Jon Burgess wrote:
> Did you try turning off the NET_MEDIATEK_OFFLOAD and NET_MEDIATEK_HW_QOS config options that the 424a9ae128bd patch added?

Where should these config options be changed?

Vlastimil Burian commented on 09.11.2018 02:05

I tackled this 3 days... 3 days of non-stop work, so I would like someone to:

1. Assign Severity: High as I really think IPv6 is important.

2. Assign Priority: at least Medium for God's sake, sorry for my wording, but I really would expect 2018/2019 be The year of IPv6.

3. Please, I beg you, find the problem and destroy it for good!

All of my provided information is / will be tracked on


Henry Gebhardt commented on 18.11.2018 16:40

Jon Burgess wrote:
> Did you try turning off the NET_MEDIATEK_OFFLOAD and NET_MEDIATEK_HW_QOS config options that the 424a9ae128bd patch added?

I finally had time to test this. Such an obvious thing to try! It works! I have IPv6 now!

If others want to test as well: I added the line


after line 62 of the file target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/mtk_eth_soc.c. My understanding is that the other option doesn't affect my hardware; it only affects MT7623.

Tim Weiss commented on 03.02.2019 21:14

I also have this bug on a wrt32x (cortexa9) with 18.06.02.

IPv6 works from my ISP (Optimum Online in north New Jersey US): If I connect my Windows 7 computer to my modem then says everything works.

From the OpenWrt device:

# ping6
PING (2607:f8b0:4006:81b::200e): 56 data bytes
ping6: sendto: Permission denied

# ifstatus wan6

"up": false,
"pending": true,
"available": true,
"autostart": true,
"dynamic": false,
"proto": "dhcpv6",
"device": "eth1.2",
"data": {		


JC Hulce commented on 09.02.2019 19:49

Here's the commit that broke IPv6:;a=commit;h=424a9ae128bd2045cd4bfd6e3229f2529d150a25
ramips: implement hardware NAT offload for MT7621
author John Crispin
Fri, 23 Mar 2018 06:42:56 -0600 (13:42 +0100)
committer Felix Fietkau
Fri, 6 Apr 2018 11:37:53 -0600 (19:37 +0200)
commit 424a9ae128bd2045cd4bfd6e3229f2529d150a25
tree 2d82652a341a08c3edb660893c20315d5cafc41e
parent dea9922acd290b37a784d354892a44684a8fb696
ramips: implement hardware NAT offload for MT7621

Supports IPv4 flow offloading on MT7621 for Routing, SNAT and DNAT

Supported are regular ethernet→ethernet connections, including one
802.1q VLAN and/or PPPoE encapsulation

Michael Adams commented on 14.02.2019 09:00

Henry's solution worked for me on my EdgeRouter-X, using OpenWRT 18.06.2. Wasn't getting DHCPv6-PD from cable modem otherwise.

Project Manager
Felix Fietkau commented on 12.03.2019 22:00

Please try this patch:

Henry Gebhardt commented on 16.03.2019 14:29

Your offload-ttl0.patch works great! Thank you!

Henry Gebhardt commented on 17.03.2019 15:34

Hm, now I occasionally get FS#1618, even after reversing the offline-ttl0 patch. I haven't seen that bug before. Might it be related?

Project Manager
Felix Fietkau commented on 24.03.2019 11:15

Fix pushed in r9707-bee7ff7cf3 (master) r7722-4336cfda12 (18.06)

Project Manager
Felix Fietkau commented on 24.03.2019 11:15

I don't think the FS#1618 issues are related to this.


Available keyboard shortcuts


Task Details

Task Editing