Just installed the firmware, will be using it tomorrow to do various things and report back.
First things first, your patch seems to be working fine 
big round of applause .
If it can maintain my torrenting stress test(few linux ISOs) + 1-2 streams of plex, this gets my seal of stability, as that was the most simple thing that would make it reboot
@db260179, thank you! BTW, where (which directory in the build tree) I should put your patch files when doing my own snapshot builds? target/linux/ramips/patches-5.10?
Hi, no problem.
So always keep an eye on https://gitlab.com/db260179/openwrt-base/-/commits/master
And look at the commit comments, will give the location on where the patches are put.
Master branch = snapshot
21.02 = 21.02 branch etc etc
I keep inline with the openwrt methodology and layout.
So for example of the ipv6 offload patch:
https://gitlab.com/db260179/openwrt-base/-/commit/c496e9cd6677930ee94a362b0670bfe959a5c9f7#510a2e01464ce562e43a693cf152d3f4279448e4 = target/linux/generic/backport-5.10
It all depends on the type of patch.
1 Like
I'm afraid all of these soc manufacturers etc dont want openwrt to know too much about their product.
Alot of these patches are reversed engineered to get it to work, based on leaked source code from the oem.
Im sure Mikrotik have the official source code or are basing on the old mediatek sdk?
Its frustrating i know, but we might get there one day at full speed.
3 Likes
@db260179 Just a quick update, 15 hours going strong, no slow-down no stutters on wifi.
I have been stress testing the router for about 3 hours now with torrent download and multiple clients connected via wifi, and iperf3, all in the same time, everything runs great , I will come back with another update in about 4-5 hours.
Regards
1 Like
What branch are you using？21.02 or master？
Is there any CPU usage during IPv6 speed test？
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
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 .
1 Like