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 :-).
Change these in /etc/config/uhttpd:
...
option max_requests '10'
option max_connections '50'
option http_keepalive '0'
...
2 Likes
Got a couple of ideas now that might be helpful, for when I get a chance. First, I see in retrospect that was a double-NAT situation, but with only my desktop computer connected to the R7800 (for configuration purposes), don't know that this would be a factor. Another is trying http in place of https. And the last is the one that I really think might be the culprit, the Brave browser...it's pretty aggressive about security and privacy, so I'm going to try the Edge browser and see if that's better. Chrome would probably be fine, too, but I threw it out of the boat when I took on Brave.
Anyways, some stuff to try when I get some clear time with no family around that's using the internet.
Any other ideas gratefully accepted :-).
install luci-app-uhttpd to change it from web interface or change in /etc/config/uhttpd file respective line to:
option redirect_https '0'
then run:
/etc/init.d/uhttpd restart
and in your browser andter router url with http:// in front
1 Like
So changing browsers didn't help, and switching to http didn't help. Leaves me with multiple NAT'ing going on. Still not seeing why that would have such a large effect with only my desktop computer connected to the R7800, but I also have a fiber gateway and an eero that were also dispensing local IP addresses. The documentation on the eero says that it's fine with double NAT'ing in router mode. My intent is to have the fiber gateway in IP Passthrough mode, and the eero in AP mode when I get done. So only the R7800 will be doing NAT. But at this point, not able to use the R7800.
At this point, have the R7800 back at Voxel (stock-ish) firmware, waiting to be re-flashed with LEDE firmware. I like a clean start for testing.
Any other ideas of why the R7800 is fatally slow will be very gratefully accepted :-). I should note that the R7800 runs the Voxel firmware at normal speed, but it adjusts its address to 10.0.0.1, so that would avoid the deadly NAT problem, if that's what the problem is.