Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
openwrt-bot opened this issue Aug 10, 2018 · 19 comments
Closed

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

openwrt-bot opened this issue Aug 10, 2018 · 19 comments
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Aug 10, 2018

hsgg:

OpenWRT-18.06 doesn't obtain an IPv6 address on the wan6 interface since commit 424a9ae. 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:
424a9ae128bd2045cd4bfd6e3229f2529d150a25
bfed38254076d576914251689a2e1f85d514783d
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 [[https://forum.openwrt.org/t/openwrt-18-06-rc1-doesnt-obtain-ipv6-address/16759/4|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 ipv6-test.com, 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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Sep 5, 2018

jedimage:

No IPV6
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.

    18.06.1

  • Steps to reproduce

    Fresh install 18.06.1 with no configuration.
    Fresh install of 17.0.1.5 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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Sep 6, 2018

hsgg:

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?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Sep 13, 2018

wiIIiam:

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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Oct 1, 2018

dtaht:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Oct 1, 2018

dtaht:

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!]

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Oct 1, 2018

dtaht:

This arm box IS getting dhcpv6-pd correctly.

root@gw1:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='18.06.1'
DISTRIB_REVISION='r7258-5eb055306f'
DISTRIB_TARGET='ipq806x/generic'
DISTRIB_ARCH='arm_cortex-a15_neon-vfpv4'
DISTRIB_DESCRIPTION='OpenWrt 18.06.1 r7258-5eb055306f'
DISTRIB_TAINTS=''

My mips and x86_64 boxes aren't

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Oct 10, 2018

byrneta:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Oct 22, 2018

jburgess777:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Oct 23, 2018

byrneta:

Jon Burgess wrote:

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

Where should these config options be changed?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 9, 2018

burianvlastimil:

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 superuser.com:

https://superuser.com/questions/1372769/ipv6-home-set-up-openwrt-18-06-1-how-to

THANK YOU.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 18, 2018

hsgg:

Jon Burgess wrote:

Did you try turning off the NET_MEDIATEK_OFFLOAD and NET_MEDIATEK_HW_QOS config options that the 424a9ae 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

#undef CONFIG_NET_MEDIATEK_OFFLOAD

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.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 3, 2019

fearless:

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 test-ipv6.com says everything works.

From the OpenWrt device:

ping6 ipv6.google.com

PING ipv6.google.com (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": {
}
}

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 9, 2019

jchulce:

Here's the commit that broke IPv6: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=424a9ae128bd2045cd4bfd6e3229f2529d150a25
ramips: implement hardware NAT offload for MT7621
author John Crispin john@phrozen.org
Fri, 23 Mar 2018 06:42:56 -0600 (13:42 +0100)
committer Felix Fietkau nbd@nbd.name
Fri, 6 Apr 2018 11:37:53 -0600 (19:37 +0200)
commit 424a9ae
tree 2d82652a341a08c3edb660893c20315d5cafc41e
parent dea9922
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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Feb 14, 2019

unquietwiki:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Mar 12, 2019

nbd:

Please try this patch: http://nbd.name/offload-ttl0.patch

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Mar 16, 2019

hsgg:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Mar 17, 2019

hsgg:

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?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Mar 24, 2019

nbd:

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

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Mar 24, 2019

nbd:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant