MT7621 - 21.02/Master feedback firmware image test - IPV6 offload and disabled Flow Control

Coming back with the results.
My wan connection did drop about 5h ago while I was sleeping, however until then , it was working great. Another thing that used to happen for me using the previous firmware is that the whole system used to freeze and drop connections, be it cable or wifi, that does not seem to be the case , as i have some active dhcp leases that are from 7 hours ago.

I checked for power loss during this time but that wasn't the case, as the router uptime is the expected one.
The only plausible reason for the dropped wan connection being either something with the router itself, or the ONT device from my isp.

What logs should I check for? Also, is there any way that I could setup an external service or something to monitor the router until we have more data ?

Best regards

So to monitor what its doing - https://forum.archive.openwrt.org/viewtopic.php?id=71532
might help

or follow https://openwrt.org/docs/guide-user/base-system/log.essentials

That way you we see what happened the next time and post your cut and pasted errors to pastebin.com.

You could look at your kernel log in webui or shell 'dmesg' to see what happened to the wan interface - pppoe-wan did? that stays there until reboot.

On a technical level the reason before it crashed the whole router, due to the flow control overwhelming the cpu - its been an historical issue with other architecture and is usually recommended to be disabled.

On cpus that can cope or have larger dma buffers or some other mechanism to cope with a large stream of data flow usually wont happen. But as micro socs like the mt7621 dont have this, it will cause issues.

It should of been an optional setting, but was always forced even from the original driver implementation.

Future patch could make this an option to turn off and on via ethtool

This is the dmesg output: https://pastebin.com/31NsK67X
This is the logread output: https://pastebin.com/G157T401

If I missed anything, please let me know.
Regards

So it seems your ISP disconnected you or just timeout - so not router issue, just the usual wan upstream issues you can get.

Wed Jan  5 02:22:05 2022 daemon.info pppd[3714]: No response to 5 echo-requests
Wed Jan  5 02:22:05 2022 daemon.notice pppd[3714]: Serial link appears to be disconnected.
Wed Jan  5 02:22:05 2022 daemon.info pppd[3714]: Connect time 1680.7 minutes.
Wed Jan  5 02:22:05 2022 daemon.info pppd[3714]: Sent 2918080850 bytes, received 2414274221 bytes.
Wed Jan  5 02:22:05 2022 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::1%pppoe-wan: Address not available
Wed Jan  5 02:22:05 2022 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::1%pppoe-wan: Address not available
Wed Jan  5 02:22:05 2022 daemon.err odhcp6c[3890]: Failed to send RELEASE message to ff02::1:2 (Permission denied)
Wed Jan  5 02:22:05 2022 daemon.notice netifd: Network device 'pppoe-wan' link is down
Wed Jan  5 02:22:05 2022 daemon.notice netifd: Network alias 'pppoe-wan' link is down
Wed Jan  5 02:22:05 2022 daemon.notice netifd: Interface 'wan_6' has link connectivity loss

Suggestion to help with this

You also have a lot of spamming

Wed Jan  5 02:22:05 2022 daemon.warn dnsmasq[1]: failed to create listening socket for fe80::1%pppoe-wan: Address not available

I suspect your isp router doesnt have ipv6 enabled, so in the interface of the wan, turn off ipv6.

I would gladly disable ipv6 as I'm not a fan of non human readable stuff :)) , however , judging by the traffic that seems to be mostly routed trough the ipv6, wouldn't that kill my network/affect the performance ?

Regards

It seems to be an issue others are having - PPP and dnsmasq issue - #15 by 9000000

So yeh, dnsmasq issue for now, so keep ipv6 enabled

1 Like

Tested on Xiaomi R3G v1.

I have ISP with D:1Gb/s U:200Mb/s
Test executed on nperf.com
In get IPV4, D: 920Mb/s, U: 220Mb/s
In get IPV6, D: 900Mb/s, U: 220Mb/s

0% usage with ipv4 and ipv6 speedtest.
0 error on logread.

I run router for 1h with your build.

Setup:
ISP(bridge mode) -> Xiaomi R3G v1. (no ppp, only dhcp and dhcpv6)

I don't have netdev timeout before.

I continue testing: Now with 21.02 SNAPSHOT build (kernel 5.4) and updated flow control patch (only for mt7621 SoC). It works like a charm:

@JulioMC @eduardo010174 @cosminmocan Thanks for the feedback so far, looks good!

Please state if you had the netdev timeout before using the flow control patch.

Thanks

For the ipv6 patch, i've requested to be applied to the openwrt master:

But it might have to go further upstream to the kernel first, so see what happens

2 Likes

Sorry if this is not the place, but:

  • is IPv4 HWNAT fixed and working in master build?
  • if I understand correctly, this build/patch only enables IPv6 HWNAT?
  • is the IPv6 packet dropping solved in master when enabling software offload? (that used to happen on 21.02.0 release)

Yes, on this build and on offcial snapshot release.

No. This patch enable ipv6 routing on HW. No NATv6 on HW. This HW not have support for NATv6.
Have support for
image
creds: https://www.mediatek.com/products/homenetworking/mt7621

I don't think answer what this error. But with SW and HW enable on firewall no have any problem. but wait for @db260179. For answer correctly for this problem.

1 Like

eduardo is correct, The code is using the PPE (Packet Processing Engine) via the SOC to do the packets.

Unfortunately it can only do HW nat for ipv4 only, but can achieve ipv6 routing only. It has limited buffering so can't do both and reason only ipv4 nat is enabled.

I've just added the ipv6 routing offload, which can help in many scenarios.

To answer the other question

Looking at the latest rc for kernel 5.16, there have been a few patches that might fix that issue. Will have a look to see if was added openwrt master.

2 Likes

To answer my query, yes the latest master has the latest fixes from upstream.

@vladuz1338 Give it a try from my above link download, and feedback

1 Like

@db260179 Before using your patch, I did have the issue, but since installing the patched firmware, all is good under the sun :slight_smile: .

1 Like

Sorry for the dumb question, but usually for IPv6 we don't need NAT since every device gets a valid public IPv6 address with IPv6 prefix delegation, right? In this case and with IPv6 firewall active, will this patch accelerate IPv6 in this configuration? (I would assume yes since firewall is "just" routing with filtering with IPv6, no NAT involved).

1 Like

I bought another mt7621 device, an archer c6u.
Currently using it wifi fast roaming, if needed it can always be repurposed for testing purposes :slight_smile:
Impressive performance until now, the xiaomi mi4a gigabit has 1d + of uptime and still going strong.

Another day another logread, after more than 21h + of connectivity , the wan connection reset itself.
I am pretty convinced that it's not the routers fault but I am curious if that is true.
Logread: https://pastebin.com/mLpqR3r3

If you scan the log for pppd - you can see what has occured, just google the message i.e. LCP terminated by peer (User request)

Fri Jan  7 05:14:27 2022 daemon.info pppd[2649]: LCP terminated by peer (User request)

Helpful guide:

So when a connection is terminated by the LCP your device gets a notification titled ‘LCP terminated by peer’.

Ninety-nine percent of the time it’s the ISP terminating the connection to your router. So our advice is to contact your ISP, it can be a momentary fault in their servers or your internet bill left unpaid for months. Otherwise, it will be a technical issue with your router that only your ISP personnel will be able to fix.

To expect 100% does not exist, you could ask your isp for any info. But your issues are not router related just the good old internet infrastructure and the problems it brings

1 Like

I saw that, that's why i said I'm almost sure it's not the router.
Thank you for the confirmation.

1 Like

So NAT was mostly for ipv4 and to do a simple protection against exposing private ip addresses on the internal network.

These days you would rely on good firewall rules to prevent ipv4/ipv6 leaking etc.

This patch would accelerate the ipv6 routing via hw.

So yes, you are correct, but should always evaluate your ipv6 security policies.