I loaded V1.12 plus the hotfix from V2.04. The router carried 14 to 16 connections and it ran for 18 hours and then rebooted. During this 18 hour time period there were 8 to 9 wireless 2.4 Ghz connections which were stable over that time span.
Other user and I, we are testing the next build. Currently, my two devices have been running without crashing for 5 days. I will wait the reports from the other tester at day 7, and at that moment I will declare it stable under the v2.06 version and upload it again. After that, the v2.10 (I will name I differently this time) will have the wireless amplifiers enabled and it should be working with a performance similar to the factory firmware.
1 Like
What router do you have that has MT7621 and what Openwrt FW load are you using? I have an EA7300V1 that I believe has a MT7621A. I am currently running factory FW on it but I would like an Openwrt load if one is available that is stable.
That sound really good!
It's likely the EA6350v3 would already have the amplifiers enabled since the 5Ghz chip is the only one with an enable pin. Seems they just pull it high on this board from what you've reported. The 2.4Ghz chip can only be switched off by a power pin, so it would't make any sense at all for the designers to do that(waste a gpio and transistor). Have a couple coming in the mail so I can actually check in a couple days.
Hello, I was expecting my other tester to reach me, but he didn't. Anyway, I have good results at this point. My Convexa-S haven't crashed in more than 8 days. My EA6350v3 either, but there was a power shortage, and I can't be 100% sure about it. My Convexa-S didn't reboot because it is connected to a UPS, white the EA6350v3 is on the second floor (without a UPS).
Anyway, I have uploaded the files to GitHub under the v2.06, so anyone interested can check it out.
If what @fdm says is true (I haven't done the research yet), it is actually quite sad to know that the device is likely unfixable. I didn't want to give up, but I see no further room for improvement at this point if that's true. Maybe an ath10k guru can help, but it's certainly beyond what I can do or know.
Proof that my Convexa-S is "stable":
I got my two EA6350v3 routers in, flashed one with this firmware, and compared them against an AC66U I have laying around. The router I flashed outperformed both routers on 2.4Ghz and preformed worse on 5Ghz. Really impressed so far, though I still need to do actual testing.
If the PA were disabled, I'd expect to be able to pick up signal right next to router and lose it after ~1ft of separation.
That sounds right. Researching in the OEM source code I did not found something suggesting that they need to be enabled.
I don't know if it was a kernel or a firmware issue, and I cannot pinpoint where it started or stopped working correctly. But what is for sure is that this:
- Outperforms stock OpenWrt
- Outperforms the very first versions of itself
It is a real, tangible and measurable improvement but I lost the track of what was the exact cause.
Since v2.06 is working with minor issues, I'll come back with another public build by Feb 2021 (if I still alive, hopefully yes) and I would love to hear feedback during that time.
P.S.: Happy new year to everyone and thank you very much for your effort, patience and support. This would be impossible without all of the people involved, so enjoy our work and I wish you a better 2021.
Why sysupgrade cannot keep the settings after upgrade from a previous build, like stable and other master? What is so different? Are the memory optimizations?
Is it still possible to avoid entering manually all settings when upgrading and get reconnected easily?
Willing to test / try the new build, but as these days everyone is so glued to the online, youngsters and the lady don't easily tolerate any remotely longer internet downtime.
Thanks for your work. Keep it safe, breathe free and chill.
It is intentional and by design. The only difference, in reality, is that I decided it to be like that. There is no technical reason about that, for better or for worst. But you can preserve the settings as follows:
You can download a backup, flash the firmware and restore the backup. It may sound harder or more steps, but is actually a good practice to backup before an update, anyway.
Most settings are preserved, anyway, there are others that will revert, like the default IP and DNS server settings. All other things are not touched at all.
1 Like
Thank you for your work throughout the year. I have ported the 2 .bin files from your hotfixes in github onto Openwrt 19.07.5 and can see a huge improvement on 2.4Ghz wireless, but it is still not on par (multiply streaming) as my GL-AR300M. Maybe Candela can optimise the code further?
In the meantime, how do we up shift to Openwrt so that everyone can benefits from your hard work?
I notice after sometime have passed, some of the clients cannot go above 3mbps on speed test. Was this expected?
I loaded the revised version 2.06 on my EA6350V3 and ran it for 4 hours and the router rebooted itself while streaming a netflix movie. I thought that there must be something wrong with my router because I have suffered random reboots with all of the V2.xx versions that I have tried. So I thought that I would try Openwrt version 19.07.5 to see if that version would suffer from random reboots as well. I have now been running 19.07.5 for 2 days, 1 hour and 47 minutes with 14 to 15 devices connected with no reboots experienced thus far. My network is very stable and I plan to run 19.07.5 for a few more days to further test its stability.
The V2.xx versions all have kernel versions 5.4.xx while Openwrt version 19.07.5 has kernel 4.14.209. Could the kernel be the root cause of the random reboot problem?
Okay, I would need your help (I asked you before, but you didn't take it seriously, probably).
I think that the kernel is, for some unknown reason, doing a oops to you. I would recommend trying to disable the panic_on_oops by SSH-ing into the device and performing the following command:
printf 0 > /proc/sys/kernel/panic_on_oops
After a couple of days, I would love to have your logs. You can send me the recollected logs by pstore by downloading the /bootfs/pstore folder and, of course, the logs of the running system. You can make them zip and send them to my email.
Since it is not longer crashing for me, I really need your logs to make a proper bug report (if needed).
1 Like
Did you applied any fixes to the build 19.07.5 ? How stable was 2.4Ghz wireless?
I did not apply any fixes to the 19.07.5. version. The 2.4Ghz, for me, is stable, but the range is not very good as it was with the revised V2.06 load with the Candela fix.
NoTengoBattery suggested setting panic_on_oops value to zero, but the 19.07.5 version that I am running has the panic_on_oops value set to 1 and I have had no random reboots in almost 53 hours of uptime. I am confused as to why panic_on_oops must be set to zero for kernel versions 5.4.xx, but should be set to a value of 1 for kernel version 4.14.209? I want to run 19.07.5 for a few more days to be certain of no more random reboots.
Because I need the logs to fix this, everybody says that this does not work, but nobody wants to help with their logs.
The idea is to allow the kernel to keep running when the oops happens. opps are not deadly problems (most of the time) unless you are running a kernel with panic_on_oops set to 1; that's why panic_on_oops set to 0 will allow the device not to reboot and gather more information about the running kernel when the oops happens to see it's side effects, dump symbols, check what the device doing when it happened, etc...
Of course, it isn't beneficial if nobody is willing to help me to fix this. Why does this crash happen? I don't know. I know that it was a generalized problem, but for me, it no longer crashes. It may be a conflictive configuration or noise in the electric line. I don't know, and I can not know if nobody wants to share the logs.
What was the point of enabling pstore and creating a wonderful script to recollect the logs, making it 0 worries a piece of cake; when nobody wants to share them? I wonder if I am asking too much. Tell me, because I don't think that asking for basic debug information is an impossible challenge.
At this point won't matter. I won't touch this until February because of my users' lack of help. I focus on studying rather than guessing the problem without a single line of logs or otherwise useful information.
Happy new year to everyone. Enjoy your new year, and I hope is better for all of you. See you in February.
3 Likes
I understand and I agree. I decided not to run 19.07.5 any further than 55 hours. I have now loaded your new V2.06 plus Candela.tar.gz and I set the value of panic_on_oops to 0 instead of 1. It has been running now continuously for 13-1/2 hours with 12 to 15 connections. I see that some data has already been collected in the bootfs/pstore folder but nothing yet in the /sys/fs/pstore folder.
OK, the router rebooted itself after an uptime of 16 hours running V2.06 and with the value of panic_on_oops set to 0. When the router came back up (rebooted) the panic_on_oops value had defaulted to 1. I will need to remove the router for a while and reinstall the Netgear as the wife has to do some important work and needs a stable network.
Good afternoon, greetings from Venezuela, I have an ea6350 v3 router, I just installed the Custom ROM v2.06 version and I'm doing great, it's very stable and the 2.4 Mhz wifi network is going great and it's much more stable than the official version 19.07. 5, thank you for sharing your experiences.
I'm new to this topic also from openwrt, I have some questions, is there a way to translate the Spanish version ????? In case you want to go back to the stock version, I just do it by updating the official version?
Thank you
If you are running V2.06 FW and you want to reboot to the Linksys FW. From the dashboard click on system, then click on advanced reboot, then click on Reboot to alternate partition. The router will then reboot to the partition with Linksys FW.
1 Like