Why is no one recommending the absolute beauty that is the Ubiquiti Edgerouter X is beyond me. Hardware offload, small, lots of space. Yes, it doesn't have wifi, but I'd treat that as a good thing.
1 Like
Because hardware offload seems to cause instability in come cases, no wifi, debricking isn't user-friendly and it's MIPS instead of ARM to mention a few things...
Because hardware offload seems to cause instability in come cases
Sure, but it's not like competing arm socs are stable to begin with.
no wifi
Seeing the state of opensource wifi I'd wager that's a good thing. ath10k is crap, mwl is less than stellar as well, and the mediatek chips are only now starting to appear, with the driver not in mainline as well.
debricking isn't user-friendly
If you update to any 2.0 edgeos before flashing openwrt you get a new bootloader which supports tftp recovery
and it's MIPS instead of ARM
If you want to treat your router as a thing which runs apps then maybe, otherwise a good thing. Even on software offload it does linespeed routing with cycles to spare, my old ipq8064 couldn't do that.
1 Like
IPQ4*** or Marvell are just as stable or even better in my experience (yes, I have all) at least running master branch.
No one forces you to even include drivers if you don't want to but I have ath10k-ct and mwlwifi (5Ghz) running just fine including WDS. That said, 2.4GHz can be mixed bag at least on WRT3200ACM in my experience.
Regarding debricking you still need a serial cable to engage TFTP recovery as far as I can tell? It might not be a huge deal but it's still one more step to do...
You don't necessarily need lump all ARM SoCs all together, IPQ (QCA) doesn't have as good support upstream as lets say Marvell (ARMv7 and better) but IPQ401X is pretty decent for what it is and I'd say that it has "better" support than IPQ806* at least for now however newer kernels have better support (better performance).
1 Like
I'll grant you that I got disillusioned by ARM after getting a C2600, and don't have any ipq401* device. They were supposed to deliver gigabit routing, and it turned out really fast that not only they can't do that without special accelerator cores, they're actually slower than the qca mips cores they were replacing.
I already voiced my opinions about ath10k-ct some time ago : it's noble, but it's only one person who's trying to fixup what mess qualcomm did with ath10k. Look at the github bugtracker. I'm glad it works for you, but it's not something I'd feel comfortable deploying in a production setting, especially since a couple of those are mine, and the response is "tough shit, I don't have a qca9980, it's abandoned by qca anyway". Which again, I hold no grudge over, but it's a far cry from the support that ath9k got by virtue of being completely opensource
And no, with the new ER-X bootloader, you just hold the button for 30s and it runs a tftp server. No serial dongle required anymore 
https://help.ubnt.com/hc/en-us/articles/360019289113
1 Like
What's the most compatible chipset/wifi you can get with OpenWRT? Or the best generally for decent driver support?
Make that: The best for ~50€
Has anyone spotted any ipq40xx bargains?
The ea6350v3 and NBG6617 are currently substantially more expensive than a year ago.
1 Like
The ASUS RT-ACRH13 is only 45$ right now on amazon:
With 128 MB of RAM [edit: and dual, ath10k wireless], this is a "non-starter"
See multiple threads around the lack of stability of its sister, the RT-AC58U, such as
2 Likes
Yes, Ive seen the threads.
I have openwrt on this router for about a year and a half, never had any problem with it crashing.
I have about 10 devices, most of them 11n and about 3 AC, one is my desktop with 200Mbps broadband, maybe its not enough to cause any problems.
Netgear ac1200 6220 is currently 56€ on amazon.de
I recently "upgraded" to this from a Linksys 3200acm and would take the mt76 again in a heartbeat.
1 Like
What? There is nothing good about having a slower CPU! An ARM based device can do network related functions (e.g SQM) much faster.
What ARM processor devices are supported best if you forget about the price?
There are different opinons about what best supported means, but mvebu based plattforms (like wrt1900, 3200, ad turrus omnia) and ipq806x (like r7800) seem to work well for quite a number of users.
Sure there are a few issues about configuration and dual-coreness in the light of frequency scaling and power saving that need attention by the user, but over-all these are supported decently.
If upstream openwrt is not a hard requirement, I would say that the turris omnia with its turris os version of openwrt (pretty close to upstream from TOS4 onwards) is quite nice as it has an active developer (that sells the units) that offers automatic updates and over all manages to do a decent job.
@moeller0 yes the marvell chips seem interesting, but not a huge upgrade over mt7621 (zbt-we1326) for my purposes. I think MT7621 has been excellent for all intents and purposes.
Currently I have no CPU bottleneck, but I do not use SQM as I do not seem to need it. So I can't tell what would happen if I used it. Perhaps I would have CPU bottleneck
About Turris, I would rather not divide community by supporting another OS which is a fork of OpenWRT. Reminds me of LEDE The guys who did Turris OS seemed to want to give freedom to users. So they could as well support OpenWRT directly and use OpenWRT on their devices. It is just wrong that they fork it and then make it incompatible. I do not want to end up with 100s of device OSes to choose from.
2 Likes
Well, then just keep using it, the status of best supported anything is prone to change over time, and in say 2 years who knows which arm soc is considered the best match for openwrt... 
It is not really a fork, after their initial approach with a soft fork they switched to something were they try to implement TOS as openwrt plus some additional packets, but sure the turris project is not for evertbody, although they are IMHO good neticens and try to upstream relevant changes to all their upstream projects including openwrt. I am not sure whether your assemessment of the turris project might not reflect the past more than the presence...
1 Like
@moeller0 You may be right for now, and I may be having some paranoid conspiracy theories But they should NOT have forked it to begin with. Do you know about EEE? It is just for show that they look like they upstream the fixes, they will eventually become incompatible enough to stop it.
Simple logic dictates that if they were to upstream all the fixes, they would not need to fork to begin with. They want to become independent and incompatible. Otherwise, they could build TOS as packages over OpenWRT same as how LUCI works right now. Just make your own user interface if you do not like the existing one or you want to customize it.
Would you prefer if many OpenWRT users moved to TOS and OpenWRT becomes a dead project? It is nice to have options, but sort of kills the usability of the software. You end up with 10 different OSes with different bugs and user bases. Just messy!
Why? From the beginning they wanted to do a few things differently, so it was clear that pure OpenWrt was not the right solution. They explored and started to diverge into basically a soft fork more out of necessity IIRC than by desire. When they considered how to update close to current OpenWrt they realized that closer tracking of OpenWrt would require changes in how TOS is cut and distributed and then went and implement those changes. From my end-user perspective, I would say the turris team has been pretty good and they improved over time.
I actually believe this to be not correct, they went the route of a soft fork first and after realizing the down-sides of doing so they worked hard to get close to mainline OpenWrt. Sure it is not guaranteed that they will stay there forever, but their intentions and current execution are quite decent.
And simple logic ignores, that upstream often does not want to take a patch/fix/feature in time for a release or not at all, for a number of good reasons, but if that patch/fix/feature is necessary for a derived distribution like Turris os, than what options are there realistically?
You pretty much decsribe how TOS >= 4 works. How about you have a closer look at how the turris team handles things today, before we continue this discussion?
I consider this to be very unlikely, TOS exists only to expose all the features and promises of the Turris project on turris project hardware, I neither expect all users to switch to turris hardware, nor that the turris project will lead to anemia of the OpenWrt project.
Again, please have a look at the current reality first, before committing to an opinion. I am not saying your opinion will change, but the facts have changed enough that a reconsideration might be in order.
3 Likes
This notion of forking OpenWrt code is getting a little off-topic. If you care to continue that discussion, please start a new thread.
Now back to "Best OpenWrt router for ~50€?"... Thanks.
4 Likes