search

openwrt / openwrt

This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins. We will continue to accept Pull Requests here. They will be merged via staging trees then into openwrt.git.
Other
20.28k stars 10.49k forks source link

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

Closed openwrt-bot closed 5 years ago

openwrt-bot commented 6 years ago

hsgg:

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: 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:

  1. 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 commented 6 years ago

jedimage:

No IPV6 Supply the following if possible:

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

dtaht:

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

openwrt-bot commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

byrneta:

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

openwrt-bot commented 6 years ago

jburgess777:

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

openwrt-bot commented 6 years ago

byrneta:

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?

openwrt-bot commented 6 years ago

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 commented 5 years ago

hsgg:

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

#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 commented 5 years ago

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 commented 5 years ago

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

openwrt-bot commented 5 years ago

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 commented 5 years ago

nbd:

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

openwrt-bot commented 5 years ago

hsgg:

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

openwrt-bot commented 5 years ago

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 commented 5 years ago

nbd:

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

openwrt-bot commented 5 years ago

nbd:

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