That one ...
1 Like
eventually, i did a big jump forward from r9945 to r12138
so, first time with -ct drivers
well, they did a veryy good improvement, also y samsung devices are ok but.. i have TERRIBLE wifi performance with my esp32 devices! average ping 1s (!!) with 30% of packets loss
is this a known behaviour? is there anything i could try?
thanks a lot
This might not work at all, but you can try setting both Fragmentation and CTS thresholds to 2346.
If that doesn't work, try 1564 / 1565 correspondingly.
If that doesn't work, try 1564 / 1564.
If that doesn't work, try 1564 and 512 combination.
But again, it might not help.
it seems disabling this option
"Disassociate On Low Acknowledgement"fixed the esp32 connection.
Esp8266 still has some problems reconnecting after deep sleep..
sorry hnyman for the off topic
Will WRT3200ACM build work on WRT32X? WRT32X has the same hardware. Is it very different to compile for WRT32X, too?
Your R7800 builds are just great!
I compile for WRT3200ACM just for testing the CPU frequency scaling driver for mvebu. You can read (old) discussion about that ( CPU frequency scaling driver for mvebu (WRT3200ACM etc.) ). But I am not publishing a real community build for WRT3200ACM.
WRT32X would run my WRT3200ACM firmware, I think, but would require forcing in sysupgrade. If you want, you can download there my build env and build for WRT32X by yourself.
But that has nothing to with my R7800 build that this thread is about...
Without being familiar with the device, I'm sceptical about that, as the partitioning differs - yes, it should flash, but then crash on boot, due to the hardcoded DTS partition table.
Correct, it will not run without modification to the bootloader vars. Also the bootloader is expecting different compression on the images.
There's no merit in cross flashing the WRT3200ACM / WRT32X once on OpenWrt.
1 Like
ct vs non-ct
it seems (credits to @wired for this 
) that ct drivers can work with non-ct firmware, and the resulting wifi seems better (at least for me, in terms of devices compatibility)
given that i can't understand why this works, i just wanted to report that building with incoherent firmware and drivers (as above) WORKS
maybe this should be a better option than the "crashes" version
thanks again to @hnyman because having a custom rom is as easy as hell based on his work..
Well I learned about it somewhere here in this thread, I did not come up with it, I just spread the word.
Thank you! Found out that WRT32X might be the same as R7800 or second best router with OpenWRT and just thought if I can use one of your builds on it, too. Should go dig and try building with your env. then.
Sorry for the offtopic. And thanks again for the great R7800 build and your work!
master-r12171-ae61d21ca3-20200203
I added wireguard support to the build, as there seems to be some interest for it.
Wireguard was added a few days ago to Linux upstream (and will likely hit kernel 5.6), so its use will likely get additional popularity.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd2463ac7d7ec51d432f23bf0e893fb371a908cd
Newest master build has it already, but I will also add it to the 19.07 build next time.
2 Likes
Is wireguard like a VPN service? Do you need to pay a monthly fee? Who is recommended to use for the service?
i assume there are changes in the menuconfig and a updateNmake is not enough, right?
Simply add CONFIG_PACKAGE_luci-app-wireguard=y to .config.init recipe, and it will pull the needed dependencies. No actual source code changes from me, except this addition to the recipe.
(If you are building by yourself, then my addition has no special value for you, as you can add any desired package in any case...)
Not sure I would agree there. The pure wired perf of the 32X (and most WRT) are very good. But the WiFi is not apples to apples. R7800 is QCA based and continually developed. WRT's are on mwlwifi, and abandoned with bugs.
Hi @perceival.
Regarding the performance of the master build from 2020-01-23. I'm seeing the same thing (on Wifi). I'm unsure if the tests I did showed any change with the 2020-02-01 - in either case they are both a bit The wired routing performance seems unaffected to me.
On the other hand I haven't seen a spontaneous reboot and 9d uptime - which is a world record in my house.
Br,
Martin
Having an odd problem here. I just flashed R7800-master-r12158-ffbb8ed5a2-20200201-1548-factory.img on my R7800 on top of stock Netgear firmware. I've had previous versions of LEDE firmware working well on this very R7800. After the flash this time, LUCI is so slow that I'm getting red command timeout error messages. Way too slow to be usable. I've tried some basic stuff, like power cycling and resetting the router, but it insists on going way too slow to be useful. I know that this could be the Windows PC that I'm using as admin console, but I don't see anything unusual there, either.
Any ideas how I can go about figuring out what's going on here? It's been a while since I've used LEDE firmware, and that isn't helpful in figuring out the problem :-).
Thanks very much for any help!
Try using HTTP instead. If you will see improvement add web certificate to trusted ones or install valid cert.
Must be something new...haven't tried this yet, but this wasn't an issue last time I used LEDE, like about a year ago? I did recognize the "not secure" message from my browser when I brought up the admin web page, but don't recall having LUCI be so glacially slow back then.
Using the Brave browser, by the way. Which has proven to be the fastest browser I've used.
Out of interest, how would I switch between https and http? Been looking around and haven't found a clue yet :-).