3 days running on Xiaomi R3G v1.
For me the patch for ipv6 is ready for merge.
1 Like
Reporting back with great results, 2 devices based on mt7621 with 2d+ of uptime:
Xiaomi 4a gigabit: 2days and 6 hours
TP-Link archer c6u: 3 days 10 hours
As @eduardo010174 , the patch is ready :))
1 Like
Has anyone tested the patch to disable flow control with a snapshot build (kernel 5.10)?
I just included this patch on my build I did 2 days ago and it started rebooting randomly multiple times a day. I will try a new build without the patch to check if it makes any difference. BTW, testing with Archer C6 v3.2 with SW/HW flow enabled.
1 Like
To diagnose what issues you are having, make sure to follow guides below:
Having syslogs of the router overtime will help what caused the hard lock or reboot.
The flow control disable patch is to help minimise the netdev tx timeout issue. But due to a unknown bug with mt7621 soc, a certain load condition can cause hard locks.
A lot of issues can occur based on usage and model type. So monitoring overtime will help identify this issue.
My two models i have are Xioami mi4ag gigabit model and a unielec u7621-01, my usage on both is only a couple of users and two devices connecting to it and only using ethernet via routes and not using pppoe.
I've experienced the netdev tx timeout issue a couple of times before this patch on 21.02, since no lockups or crashing.
Any other error is an unknown and could be unique to the device or situation.
1 Like
I just installed a new snapshot build without the patch, it rebooted as well. So the issue is not the patch, but in fact Kernel 5.10 is really unstable on mt7621 (or at least on the Archer C6 v3.2). I've already reported this issue in another thread here (this issue only happens when SW/HW flow offload are enabled).
I also own a Archer c6u , the non u version has a different SOC.
You you want , I can replicate your tests for additional logs/tests
I understand C6 v3.x and C6U v3.x uses the same SOC, being the only difference the USB port that the C6U has and the C6 doesn't have. See below.
Both are MT7621DAT (SOC), MT7603EN (Wifi 2.4Ghz) and MT7613BEN (WiFi 5Ghz).
At least I can confirm this info for the C6 3.2, since I updated the second link below.
You are correct, I looked for the c6 and c6u about a week or 2 ago when i was looking for a secondary mt7621 device, and I probably saw only the older version.
My bad
@db260179
After more than 12 days of uninterrupted service I can safely say that this device is now openwrt-stable.
Now I'm trying to install wireguard and I'm receiving the following errors:
Collected errors:
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.92-1-7318552cb8f6798b0a6d707a2f563d94) for kmod-crypto-lib-blake2s
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.92-1-7318552cb8f6798b0a6d707a2f563d94) for kmod-crypto-lib-poly1305
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.92-1-7318552cb8f6798b0a6d707a2f563d94) for kmod-crypto-lib-chacha20poly1305
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.92-1-7318552cb8f6798b0a6d707a2f563d94) for kmod-crypto-lib-curve25519
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.92-1-7318552cb8f6798b0a6d707a2f563d94) for kmod-udptunnel4
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.10.92-1-7318552cb8f6798b0a6d707a2f563d94) for kmod-udptunnel6
* satisfy_dependencies_for: Cannot satisfy the following dependencies for wireguard-tools:
* kernel (= 5.10.92-1-7318552cb8f6798b0a6d707a2f563d94)
I know I can solve this by including wireguard in the firmware when compiling, so here is my question, besides cloning your repo, is there anything else(besides the normal compiling steps) that I need to do when compiling the firmware so that your patch is present on my compiled image?
Thank you
Hi,
Just clone my master branch (snapshots) then build - the patches are in all of my branches
I include my custom script to build openwrt (to make life easier for me and anyone who wants to build)
or the docker build system that runs this script aswell with all of the required dependencies needed
Just needs a linux vm or linux host, i dont trust windows or macosx to build it properly, so cant help on those OS's.
Hope this helps?
2 Likes
Hi, I looked through your commits. Maybe I missed it, but are you using/integrating the 3 small patches for Baby-Jumbos support (MTU up to 2030) from here Batman on devices with DSA ... Various issues - #12 by LGA1150, that @LGA1150 pointed to? He also mentioned another patch further down-thread for another issue I was having with the MT7530, but that last one wasn't applying cleanly.
Im only focus is on the offload and disabling flow control, nothing else.
If you follow the https://openwrt.org/docs/guide-developer/toolchain/use-patches-with-buildsystem guide on creating a openwrt patch, you can then make a new patch in the 5.10-backports that will cleanly patch on build time for openwrt.
There will be some sort of manual fitting the changes, but its easy to understand from the link i provided.
You can then do a pull request to my gitlab, which i can then try and push upstream.
offtopic:
@db260179 patch for ipv6 have problem for merge on github?
15 days no change and not merged ...
I'm new on working on opensource projects. What is the steps to merge on patch?
Well, it looks like it needs to go to the netdev mailing list first, then will be backported to openwrt.
I haven't had the time to try and send an patch email to that netdev list. I find the mailing list a very antiquated way of doing things, so it will be a while, unless someone else can do it?
1 Like
The very next message in the thread I linked was me describing successfully doing just that. With a link to a ready-to-use patchfile, that applied cleanly on r18612 master from yesterday.
So, I'll probably just try with cherry-picking your
commits, that seem to contain the meat of the changes.
Ok, wasn't sure what you where getting at?, but yes, feel free to cherry pick my changes.
Ideally get them pushed to upstream so everyone can benefit these fixes.
Also look at https://gitlab.com/db260179/openwrt-base/-/commit/098341f8c501b6a0796c73fb89e1eebac72c0ca9
I did for 21.02 branch, and just use the ifdef statement so its specific to the mt7621 soc on the master change. More likely to get added to mainstream if it only affects soc mt7621 devices.
2 Likes
I have several MT7621 devices, and run into problems with them one-after-another attempting to integrate them into Batman mesh networks, using wired and wireless links. One of the problems was crippled MTU-settings, that forced fragmentation on all backhaul packets, if wanting to keep 1500 for the payload LAN MTU. Then there were the problems with IPv6 traffic disappearing, the CPU SOC port loosing 16% performance, because the PHY is not correctly set to trgmii without 2 trivial DTS-patches. On top of that there are the ton of changes/regressions with DSA w.r.t LACP, VLAN-aware-bridges. I currently cannot add a switch.VLAN# interface to a bat0 master, thus using a specified VLAN for wired backhaul becomes impossible.
So I have been on the lookout for others maintaining/collecting patches for the MT7621/MT7530, that have somehow been forgotten. And your patches looked more complete than mine, so I thought, you had maybe integrated the MTU/TRGMII patches too.
Oh, and thanks for the link to the FC-patch with surrounding IFDEFs.
From my understanding, the bottleneck in the router is actually the firewall, not from the NAT functionality. NAT basically just replaces source/dest IP and port and let the packet flows thru. It is the firewall rules that slows down packet thruput.
The implementation of the flow offload solutions, whether it’s the Linux native solution or from QCA fastpath basically skip the firewall (or more specially netfilter) rules for established connection. For hardware NAT, it’s basically the same. It’s only enabled for established connection and it has the necessary lookup to replace the IP and ports.
So in short, IPv6 with firewall will see the same slowdown. Probably a tad slower since IPv6 packets have higher overheads.
Could you share your current mtu backport fixes?, i would like to add to my gitlab repo.
Thanks
1 Like