I don't want to replace ARM with RISC-V. I want ARM and RISC-V to compete with each other, micro-architectural progress to continue, and to be able to pick the best part for each task.
OpenWRT is remarkable in how many architectures it supports, with both ARM and RISC-V available. This just happens to be one board and it uses ARM, but it could easily be moved to an official RISC-V one when available with enough support to meet their demand.
P.S. you don’t get to start calling things “legacy” just because you would prefer something else. ARM is clearly at a scale right now where that’s the sweet spot for cost/performance/availability right now.
I run OpenWRT in a few locations. One of them is VM on a x86_64 fanless (SuperMicro) server hypervisor. The other is a VM on a x86_64 fanless CompuLab FitPC hypervisor.
ARM is legacy because it predates the open ISA standard.
I am interested in this, even if it is based on legacy ISA ARM, as I would rather a hacker-friendly router designed for OpenWRT.
This is relative to some consumer device off the shelf which is hostile to OpenWRT, needing trickery to just install. That is what I had in my previous location, and I would prefer this instead.
That's a weird way if putting it. By that logic, a current Gen Intel CPU is also legacy. It might be carrying a lot of legacy cruft, but calling it a legacy architecture seems just wrong.
It is very possible to make a great modern implementation of a bad ISA full of legacy cruft; Zen4 is a good example of that. Intel get a participation award for trying.
Maybe but I think going with middling ARM chip is more the right call then trying to pursue a RISC-V based chip. The OpenWRT folks don't have the needed logistics chain to distribute this at all, and it sounds like they're leaning hard on both MediaTek and the Banana Pi team for this. I don't know of anyone else off the top of my head that would give a bunch of open source devs working on a niche distro that kind of support.
That said, the VisionFive 2 is available. There's some people on the Openwrt forums working on trying to get OpenWRT to work; might not be a bad idea to reach out to them and see how far they've gotten.
That is not what that word means. There will be more new ARM CPUs shipped next year than RISC-V CPUs. It is actively developed and improved. And this trend of people calling existing ISAs "legacy" when they're not is really annoying.
Have you heard the phrase "extraordinary claims demand extraordinary proof"?
You're asking yjftsjthsd-h to furnish data to make a slam dunk conclusion that ARM-licensed CPU designs will out-sell RISC-V.
You realize Apple Silicon is ARM, right? And 99% of all smartphones that have been sold in the last decade, and indeed in 2023, are based on ARM cores?
We are talking hundreds of millions of devices being built and sold each year, just in the phone+PC space. That's ignoring all other verticals where ARM designs can be scaled up/down to meet.
I mean, gosh, even if virtually EVERY company in the world, EXCEPT Apple, chose to drop all ARM IP tomorrow and switch to RISC-V, there'd still be a good chance the statement "There will be more new ARM CPUs shipped next year than RISC-V CPUs." would still hold true in 2025: Apple sell a lot of computers in various sizes, you know :)
> You're asking yjftsjthsd-h to furnish data to make a slam dunk conclusion that ARM-licensed CPU designs will out-sell RISC-V.
I think the statement that was made was slightly different: that there would be more newly shipping ARM parts than RISC-V parts (to show that ARM is still actively developed).
Which seems very likely, but is not quite a sure thing for 2025. (And it depends upon how we count: lots of RISC-V wins inside proprietary SoCs is probably not quite what we mean, but instead new RISC-V COTS parts we can put into our designs; but if you count the former RISC-V probably looks much better).
>> You're asking yjftsjthsd-h to furnish data to make a slam dunk conclusion that ARM-licensed CPU designs will out-sell RISC-V.
> I think the statement that was made was slightly different: that there would be more newly shipping ARM parts than RISC-V parts (to show that ARM is still actively developed).
I actually thought about it at the time and left it ambiguous because I believe both; I believe there are and will be more ARM designs, and I also believe there are and will be more physical ARM chips manufactured.
> I believe there are and will be more ARM designs
Just out of curiosity, what does ARM designs mean here?
- New distinct processor cores available?
- New distinct parts I can buy at DigiKey and through other channels that include an ARM core?
- New distinct chips taped out using an ARM core, including vendor specific chips?
The latter is where I expect RISC-V to surge first. Probably not passing ARM in 2024, but threatening to do so. It's pretty easy to get rid of a license fee at this point unless you need extreme performance or are really picky about tooling.
ARM may not win on the first measure, either, but that's largely the vagaries of how roadmap packs into a calendar year.
There's also the whole question of whether Cortex-M counts as ARM anymore, given that modern large ARMs no longer run the Thumb instruction set (and Cortex-M only runs Thumb).
I was thinking of tape outs when I wrote it, though again I think all those are true in the short term.
I guess we can argue semantics of what counts as "ARM", but Cortex-M sure isn't RISC-V so for the purposes of this conversation I'm inclined to unambiguously include it.
MIPS, Xtensa, and x86 aren't RISC-V, too, should we count them? ;)
It's hard to measure how big RISC-V is for vendor-specific SOC wins. There's clearly a whole lot of momentum. Performance and all of the new things ARM does aren't necessarily too relevant if you're designing a chip that goes inside a hard drive or whatever, but a few pennies a unit to ARM might be.
>You realize Apple Silicon is ARM, right? And 99% of all smartphones that have been sold in the last decade, and indeed in 2023, are based on ARM cores?
Emphasis on "cores". Relative to each one of these application processor cores, how many embedded smaller cores doing specialized tasks do you think there are?
Are you aware RISC-V already has penetration there? Do you know how e.g. the popular Qualcomm SoCs have shipped a bunch of RISC-V cores for a while already?
Are you aware the companies behind popular alternatives to ARM such as Arc or MIPS have already embraced RISC-V?
In short, what makes you think that in 2025, most of these cores will be ARM?
> Emphasis on "cores". Relative to each one of these application processor cores, how many embedded smaller cores doing specialized tasks do you think there are?
Fair point, but the context here is your original comment:
> Great idea, but not a fan of the timing yielding a legacy (ARM) SoC.
So you're talking about the main processing cores of the SoC, the one(s) that are responsible for running the Linux kernel + OpenWRT user space, right?. Not the random other 8/16/32-bit MCUs...
I meant in the next year, but it's probably true of 2025 as well.
My primary basis is continually trying to get a Linux-capable machine with a RISC-V CPU, which remains difficult. Look at the number of SBCs released each year for the last... I dunno, 5-10y? A bit of x86, a lot of ARM, and at the very end a single digit number of RISC-V boards. Which still are slow, expensive, or both. Even if RISC-V ships exponentially more boards each year it won't break even until after 2025. If you wish to offer data to the contrary feel free.
Now, there's a possible argument for number of non-Linux-capable chips, but I don't know how to gauge that; the... Cortex-M0? I think? Is still a popular option AIUI. Likewise, if you have actual evidence feel free to share.
(None of this should be read as dislike for RISC-V; I want to use it, but the market doesn't yet agree, and even when it does take off the competition won't magically become "legacy" at a result.)
Edit: Actually that last bit deserves more emphasis - while I believe what I wrote about numbers, it's secondary to the rest of the comment; RISC-V is great, but it in no way renders everything else "legacy" so long as they remain actively used and developed (the latter is important, but ARM continues to improve so the point stands).
I've seen religious zealots who are less adamant than some of the RISC-V fans. Do people really self-identify with an instruction set architecture so strongly?
But, irrational zealotry can be surprisingly powerful: Linux would not have happened without it.
So while it may seem ridiculous at times, sometimes great good (and great evil) comes from this disguised will to power, and it is part of human nature.
I think a lot of people are really fed up with the status quo.
Management engines, millions of lines of hdd controller code, bios/firmware blobs that are basically opaque, etc are annoying and prevent me from having control over something I own.
Rightly or wrongly a lot of hope is being put into RISC-V as a way of improving the situation. The open nature of it might make it easier to break monopolies, to get control back of the hardware they own.
It's not about instruction set - its about open source. No different than the people who didn't get that Linux was a big deal because they compared OS features as if that was the primary driver.
> Rightly or wrongly a lot of hope is being put into RISC-V as a way of improving the situation.
Those hopes are obviously misplaced. The ISA isn't why your hard drive's firmware is closed. Western Digital using RISC-V isn't going to make them more willing to open up about the non-CPU parts of their chips, where their competitive advantages reside. RISC-V isn't even going to make anyone change their decision about whether to design their own CPU core or license an off the shelf core. The only real impact RISC-V will have on the industry is to slightly improve the breadth and pricing of off the shelf CPU core IP available to ASIC designers—and that doesn't have any implications for the openness of products incorporating those CPU cores.
RISC-V cannot break a dam holding back companies from open-sourcing everything when that dam is entirely imaginary.
The fundamental problem here is the IP system; even open-source is just putting lipstick on a pig. The core problem is that if you pick any particular type of device, chances are that no company is building fully open-hardware devices; it's a systemic problem. What's worse is that this is a solved problem - patents originally solved this, except for some reason firmware have copyright protection despite being a functional design, and thus they are gifted the privilege of legal protection without the responsibility of publishing documentation.
What's more, firmware's copyright isn't tuned for the electronics industry - they get protection for 70+ years, when it's duration should be the minimum duration necessary to properly incentivize producing innovative firmware. That's a variable period so I don't expect it to be an easy problem, but frankly it's not even in the ballpark.
So hypothetically, we will be legally permitted to modify the firmware of today's routers in maybe 2090 - no source code though. In fact the source code might have been lost forever, because copyright was designed for books and hasn't been properly updated before being applied to software.
Patents tend to last 20 years, which IMO is a far more reasonable duration (if your 2004 router design still isn't profitable then sucks to be you, you had a very generous window) - IMO the firmware should require source code in escrow in order to gain copyright protection, and it's copyright duration shouldn't last longer than a patent would.
Can you please stop posting repetitively about RISC-V? We've been getting complaints about it becoming a tedious pattern.
You've also posted some good unpredictable comments so I don't want to ban you, but basically anything that an account does that becomes predictable is what we're trying to avoid here.
One way to not be predictable is to include unique, relevant information in your comment, as opposed to posting something shallow. Another way is to just post on a variety of different things, without too much of a pattern.
I think the second outcome is pretty much impossible. The device will be built and sold by BananaPi, which receives a license to the OpenWrt trademark in exchange for a $5-$10 donation per device sold.
The OpenWrt project does not pay its developers, so the money will only be used to cover infrastructure costs.
Infrastructure costs for a project like openwrt could be nearly zero if the infrastructure was designed with cost in mind (site behind cloudflare, free tier in Aws/Google cloud for build bots, code on GitHub, etc).
You can probably run the whole thing for $100/year of unavoidable costs (eg. Domain registration).
Also did CI/CD on OSS projects and highly agree with this - CI/CD is not free, especially if it involves anything hardware related, which is likely in at least some subset of OpenWRT's cases.
As an OpenWRT user, I am very optimistic about this. I'm sure almost all users would fork in money for this instead of going for hostile mainstream companies.
Also the USB-C UART and recovery read-only bootloader is a nice touch. Really looking forward to it.
One concern is just misplaced anger because some users misunderstand what this means for OpenWRT going forward, but I hope they'll be in the minority.
> The OpenWrt project does not pay its developers,
This is actually surprising to me, but I guess the donation money isn't enough to pay developers. Would the surplus if infrastructure costs are covered go to developers or is it all going to a rainy day fund?
Maybe that money could be used for meet-up events and other activities that benefit the project and indirectly its contributors. That seems like a safe way to spend money without getting into trouble for paying some and not others, risking the open-source spirit of the project.
Yeah, it's probably not a great idea to pay developers with the donation money. I am not sure why I thought it was acceptable, but it is obvious now why this is a terrible idea.
Prolific devs could setup a Patreon/Librepay if they'd like, but that opens up its own can of worms like false expectations/entitlement of some donators. They might prefer not to do that for that reason alone.
Coming in at under $100 is a lofty goal, but if they make the hardware, I'll buy one. The Turris Omnia was close.
I've been using (and previously contributing) to OpenWrt for almost 10 years, it's an excellent project and deserves some spotlight, I really hope this gains some traction.
If they're selling it at cost, ~$100 is not so unrealistic. It's similar in specs to the GL-MT3000 from GL.iNet which retails for $109, albeit without some of the price-increasing niceties like NVME, redundant recovery flash, or built-in usb-to-serial converters: https://www.gl-inet.com/products/gl-mt3000/
G.iNet is wholly based upon OpenWRT. They get the benefit of the free software and can undersell because they don't need to support it. I know I'm oversimplifying, but it's at least partially true.
I'm a big fan of OpenWRT. I switched to it after running pfSense for a lot of years. Anyone can donate to the project here: https://openwrt.org/donate
Fully agree, I debated editing my comment to recommend against purchasing it. I bought the aforementioned device after hearing that GL.iNet sells their devices with very minimally modified OpenWRT and that a stock image is freely available, and only after going to set it up did I learn that they no longer publish things like their uboot and kernel trees, and that the stock openwrt image for the device was community contributed. It's very frustrating and I regret purchasing from them.
That being said, a huge portion of the consumer-oriented router brands are based on openwrt/buildroot today, so they're far from the only group guilty of benefitting from openwrt without contributing things back.
I just got one of these. It is certainly supported! I am now running my own homebrewed build of openwrt 23.05.2
I updated the gl-inet firmware to the latest 4.4.6, and then flashed vanilla openwrt 23.05.2 through the luci web interface.
I played around with the uboot flasher which takes an img file. I haven't played around enough with it yet to unpack the images to see if they are different formats or not.
It sounds like you are doing the right things. I guess check the hashes to make sure the files are intact? I haven't tested other versions or snapshots.
cameroncc
December 12, 2023, 4:07am 5
Did you just use the sysupgrade image from the firmware selector? How long did it take to fully flash?
gee_one
December 12, 2023, 5:30am 6
Yes, for the vanilla firmware, I used the sysupgrade version from the firmware selector, 23.05.2.
I don't remember how long it took, but it wasn't very long. I think about 5 mins or less. I had a serial console as well, so it was easy to see that some activity was going on.
cameroncc
December 15, 2023, 4:13am 11
Well, I just reflashed the GL.iNet image from uboot and then flashed the OpenWrt sysupgrade image from luci again just like before so I could try to ssh and read dmesg before messing with UART and it just... worked... no idea why
I'm not sure what to make of your comment, what is this in reference to? The last commit on the uboot tree you've posted was 4 years ago...
I realize that 23.05 is supported on the device, but my point is that it was entirely done by individual contributors from outside of GL.iNet, not contributed by the company itself. It sucks because GL.iNet sort of built a reputation off of being the openwrt router brand, and used to be in relatively good standing, but have shifted their approach since. Now they benefit off the reputation they built previously, because of people like me who assume they're still doing that before making purchases.
"I realise the 23.05 is supported on the device, but my point is that it was entirely done by individual contributers from outside of GL.inet, not contributed by the company itself."
Not sure I understand why this would not be exactly what one would want. (Namely, people outside the company being able to get the hardware to work with an open source OS.^1) Who wants to be stuck with a proprietary vendor OS on a router, something like Ubiquiti (a company recommended countless times on HN), where the only way to get the full features is to use their OS instead of choice of Linux/BSD installed by the buyer.
AFAICT, GL.inet software is generally no better than OpenWRT or other open source projects. It's probably terrible. Why would anyone expect otherwise. Good reason to compile OpenWRT for oneself.
The GL.inet software is probably getting worse. FWIW, one can still buy the older models. The pre-installed bootloader can be replaced. For newer models, might have to contact GL.inet. It's not clear if you are suggesting one cannot get the source to the bootloader for the router you bought, i.e., you asked GL.inet and they said no or did not respond. If that's the case, then I am interested to know.
AFAIK, people bought the older models for the hardware, e.g., GB ethernet, small form factor, and being supported by OpenWRT. GL.inet is a hardware company that lets the buyer replace the pre-installed OS with their own version; this is anticipated. That is more than many companies selling similar products.
There may be better travel router hardware available today. But being known to work with OpenWRT is an important factor for some buyers. For _some_ GL.inet models, the hardware is known to work with OpenWRT and u-boot compiled and installed by the buyer. AFAICT, the models with the Mediatek 7981 SoC are not a problem. If this is wrong, please do tell.
daniel March 7, 2023, 5:38pm 33
fakemanhk:
while their MT2500/MT3000 using Mediatek chipset I might go for it since it has higher chance to get vanilla OpenWrt on it.
MT2500 and MT3000 will definitely get vanilla OpenWrt on them. I'm working on this. gl.inet has provided hardware and all necessary documentation (schematics, ...) to do this. Would of course be nicer if they'd even do that themselves, but that's too much to ask, I guess. It's quite different case from the SiFlower SoC where there isn't even any sourcecode for most drivers. For MT7981 everything relevant is available in sourcecode, just needed some work to go to upstream Linux and will land in OpenWrt very soon.
> so they're far from the only group guilty of benefitting from openwrt without contributing
This is certainly true. SoC vendors often base their SDK on a fixed version of OpenWrt and then add proprietary patches on top. Then sell the SoC + SDK to a device vendor that adds additional proprietary patches and sells the device.
The issue with this is that the only way to fix security issues is to back-port them to the exact kernel version the SoC used as a base, and after a year or two, they completely drop support and you're left with a device that has known security vulnerabilities you can do nothing about.
How many old routers are still in use that are used as part of a botnet?
A few times a year I go looking for projects to support. It's tricky because I don't want to give money to a project that has tens of thousands of dollars in their account—I'd rather give to some smaller projects or indie devs!
> G.iNet is wholly based upon OpenWRT. They get the benefit of the free software and can undersell because they don't need to support it. I know I'm oversimplifying, but it's at least partially true.
Are they complying with the license terms? I guess I don't understand why it would be considered a negative for them to build a product based on OpenWRT.
It's not a big negative from the consumer point of view. I've purchased some (3) and supported other (6) Gl.iNet products and they've been okay. Several times I have run into issues where the routers have effectively bricked the ability to update the firmware image, while continuing to operate with the outdated and insecure image still running. I've successfully un-bricked a few of them, but that can be a tricky task and takes a while.
They do seem to be complying with the license terms, and the free portions of the software can be downloaded from the Gl.iNet website.
Most of the negatives have been covered in other comments here.
As a small contributor to OpenWrt, I don't like the whole: release one version of their proprietary fork of OpenWrt and then just do security fixes on top of that.
If they really want to focus on hardware and base everything on top of OpenWrt, it would be easier for them to upstream as much as possible and let the community handle updates. Even donating would be less expensive. It would be somewhat of a win-win situation IMO.
> I'm a big fan of OpenWRT. I switched to it after running pfSense for a lot of years. Anyone can donate to the project here: https://openwrt.org/donate
Would you care to go into why you chose it over pf/Opn Sense? Considering that you have to reinstall so it's not automatic, what makes it enough better to make the change worth your while?
I'm currently running OpnSense for my personal routing and firewalling needs, and considered OpenWRT a few weeks ago (for linux driver support, but that's another story). In the end, I changed my nic and kept opnsense.
Sure thing. I don't want to make any unfounded accusations, but I observed some unstable behavior on my pfSense installations. It wasn't clear if it had been hacked, or if it was just buggy, but it seemed more like a hack to me. Because it's installed as a proprietary blob from a "trusted" source, I couldn't do much troubleshooting. This was shortly after the opnSense mockery, which reduced my confidence in the professionalism of Netgate.
https://www.reddit.com/r/homelab/comments/ssk8zj/til_in_2017...
Also, while exploring other options, I found that OpenWRT provided much higher bandwidth on the same processor/memory footprint. I was able to reduce the VM CPU and memory allocations after switching.
Finally, there were a number of features I needed that pfSense just did not support. One was IGMP snooping, another was IPv6 using a provider tunnel.
I've been using OpenWRT forever (WRT54G era) and only buy devices that can run OpenWRT. GL.iNet is my go-to out-of-the-box OpenWRT recommendation for others looking for a router. Their UI is a lot easier to use than LuCI for most things. I had a RPi-based Wireguard VPN setup to a family member's house, but I switched it out with a GL.iNet because their UI for managing Wireguard devices is so much easier. Especially since I can access it using their Goodcloud management portal from anywhere.
I hope OpenWRT pulls off having their own device. That would definitely be an upgrade from GL.iNet. But compared to getting a completely non-open firmware like every other GL.iNet competitor, even their versions of OpenWRT are a major step up.
There are a few of their devices that have upstream support in OpenWRT. But it is like buying any other device for running stock OpenWRT in that regard - you have to do your homework to make sure you get something compatible.
I still have OpenWRT running on a RPi4 'router' and 3 TP-Link routers as APs on my network. But still wish I could get GL.iNet's Wireguard management in Luci...
Sounds about correct! I have one that I bought in 2018 but I remember it being more like 450+ € at the time.
I have had a fiber line connected during the whole time and it has served me well (I haven't done much customizing on it though, I have to admit. It's just the router for my home network).
First, that doesn't make sense when there are full modern system boards that sell for a fraction of that individually.
Second, why would you need something different that what routers are already doing? They are just trying to sell their own openWRT routers, the hardware has existed for a decade at or below $100, why would it be difficult for them to meet that?
They aren’t just trying to sell a router, they are trying to make available a fully open router without blobs right from boot, that is unbrickable, and selling it essentially at cost
Where are the numbers here? How does what you are saying connect to what is being talked about in a concrete way? You are talking about software and saying it has to cost $100 or more while there are $30 routers on amazon.
This is more or less discussed in the link. They started looking at BananaPi products as a starting point, but have some requirements that existing boards don't fulfill. One in particular that probably precludes all of the $30 boards you're talking is:
"that this router isabeautiful (sic) example of excellent GPL/LGPL compliance"
These routers are crap. Anyone who cares a tiny bit about their wireless connectivity won't buy this. And I don't think OpenWRT wants to associate their name with "low-quality" routers.
What you are saying here is speculation. Most router's shortcoming is software. I've used cheap netgear routers with openwrt and they work incredibly well.
If you get up to mass-scale production quantities, $100 might be feasible. I imagine small-scale production with little up-front capital and no guaranteed market might be lot more challenging. It's not software, you're going to need large orders to get good prices.
I think about Meego/Jolla phone and tablet, Ubuntu Phone, Kobol Helios and tons of other projects that have either failed or are struggling due to market size and ecosystem.
I've been running a Turris Omnia for the last few years, which I've been fairly happy with. Network performance is about average and the platform as a whole is certainly due for an update, but stability has been great, it receives regular upgrades, and I'm happy to pay more for a project that has an open mindset. Not sure many feel the same way about commodity network hardware though.
Anything with radio involves a ton of expensive certification work.
With something like a rpi that sells millions of units, that can be spread over way more units than something like this that (optimistically) gets sold to a few thousand nerds and that's it.
As others have said, it was probably supposed to read "m.2 2242" which is physically in-between the size of the 2230 drives that the Steam Deck uses and the 2280 ones that most modern desktops and laptops use.
> GPL compliance: 3b. "Accompany it with a written offer ... to give any third party ... a complete machine-readable copy of the corresponding source code"
I'm guessing it will also be a tag from `git.openwrt.org`, from the same development and release process that continues to support numerous other consumer devices, and keep them up to date.
It might be good to clarify this, since people who've seen a lot of open source projects can imagine ways this could go bad.
I have a very favorable impression of the OpenWrt project, and I'm looking forward to this being a good thing.
RK3588 can handle 2 2.5G ports. Would bump the price a bit, but also is a significant CPU upgrade so you are likely to get much better usable bandwidth with packet inspection and/or QoS.
That’s a pretty significant jump in complexity, the RK3588 is one of the most powerful SOCs available. A cool part, but I’m not sure it fits the OpenWRT use case
What's the complexity? They start at $70 or so in the RK3588S flavor, it's basically a CPU with a PCIe bus, the software, board complexity, and cost seems just about the same as the proposed OpenWRT solution.
> Mediatek might not be willing to provide their WiFi SoC if you are not using their compute SoC
There are some China-only ZTE devices that do this, but they obviously have a different order volume and scale that makes it possible. (The main SoC is replaced with a ZXIC one, a ZTE subsidiary)
In the first case I'm dubious that MT7981B can handle usefully more than GigE with the usual small packets, firewall rules, anti-buffer bloat, QoS, numerous clients, and related that people expect of a router these days.
Seems to really limit the audience and shorten the useful life of a router to penny pinch. How about a $88 NanoPi with dual 2.5G, 4GB ram, 32GB eMMC, and wifi? Is it really worth $10 to have 1/4th the ram, 1/256th the storage, 1G instead of 2.5G and less CPU[0]?
I got similar with the faster RK3588, 8GB ram, dual 2.5 and 1G, and metal case for $120. I've been quite impressed, it's about half as fast as my xeon E3-1230 from years ago.
the turris devices are tinker friendly, feature rich and high quality - and not cheap.
truth be told, the aio router-server embedded thing seems very difficult because peoples expectations vary widely and the whole ids/dpi and media-server stuff gets somewhat more demanding at gigabit speeds than what unoptimized stacks can accomplish with commodity low-power hardware.
I see this as being the Corolla to Turris's Unimog. The Omnia is a sliders-to-the-right dreambox with every possible interface, it has a freakin' SFP slot, three miniPCIe slots, I mean, wow.
As a result, it's capable of 99% of jobs, but it's only the best choice for about 2% of them. For most things, the Omnia is tremendous overkill and nowhere near cost effective. Therefore it suffers low sales volume, and the price never comes down.
This new box might only be capable of 75% of jobs, but it should be a good cost-effective choice for quite a lot of them. It still won't be the cheapest, but it'll be reasonable, and they should sell truckloads of them.
The thread mentions it, it's basically a MediaTek MT7981B with some extra components. It would be interesting if they can get all the things they mention in the < $100 price range that they're aiming for.
What is the intended purpose of an openwrt banana pi?
I associate openwrt with router firmware/software, so I would expect a lot of ethernet ports (more than two). Or use it as a wifi router/access point, when I only need one port. If I would want to do any networking tricks, I would fall back to a rpi/banana pi, which wouldn't do routing or wifi.
I'm only curious. I have two rpi's in my drawer doing nothing.
That's how basically all consumer routers work: an SoC with about two Ethernet interfaces, at least one but usually both connected to a managed Ethernet switch chip, using separate VLANs for the WAN and LAN ports. Routing both Ethernet ports through the switch chip is usually done so that the switch can do some NAT offload.
1) providing basic networking (default gateway, connection to upstream provider)
2) basic security: firewalling + natting
3) basic network daemons, and "daemons": DNS, DHCP, IPv6 autoconf, and a nice new one: 802.11s ("network mesh": keep wifi at 5 bars by kicking people off their access point if another access point can provide a better connection)
4) more advanced networking stuff: VPN (l3vpn, l2ptp, l2ptmp, mesh vpn), cloud connections/vpns, WAN connections, redundancy (downstream and upstream, l2 and l3, ...)
On the other hand, they would sell it with direct support for real OpenWrt, while many other manufacturers, including FriendlyElec, often publish franken-Linux distros that force users to resort to others such as Armbian and DietPi to be sure their OS doesn't become obsolete and unsupported in a few years.
The difference is that OpenWrt has the entire source code available, and unlike those franken-distros, it is built as vanilla linux + a set of patches. As long as there is enough interest, anyone can rebase these patches on top of a newer mailine kernel. For example some Ubnt XW boards recently got an update to 23.05 after being stuck on 19.07.
I don't feel like it really needs to compete on price though. As long as it's not totally unreasonable, I (and I assume other OpenWRT enthusiasts) would gladly pay a premium for a device that includes truly first class OpenWRT support.
I have been looking for an open source replacement for the Elecom WRH-583BK2-S is there anything in there? It's a W65 x D35 x H20.5 (mm), dual LAN, 802.11ac router.
I'd love to see a 10g version... but it probably doesnt make sense for like 95% of the people, both in terms of specs and finantially (2x price? You probably want 2 10g ports too).
I would have pointed you towards the BPI-R4, but they haven't quite got the accessories around it out the door yet. (Ie. The 802.11be radio add-on card and the case are not available yet)
Bring it with you "home network setup" with devices pre shared keys and only authentication to a portal one time or an Ethernet port. Also let's you share one paid-for connection—on an airplane for example.
I used OpenWRT on an actual Linksys WRT device back in the day. These days I use separate components for my home network: Huawei modem, pfSense router/firewall, Unifi wifi, unmanaged switches. This gives me more control (and more learning opportunity) but obviously I see the benefit of the "all in one" type devices OpenWRT supports in many applications.
Back then I didn't really understand routing etc. and just used OpenWRT as plug and play. But is it actually a good alternative to the above component-based setup when just a single device is desired?
Hopefully you would actually be able to get a full speed transfer between the Ethernet ports; I had to go back to the factory firmware on my router in order to take full advantage of my 1 gigabit Internet connection.
If it was several years ago and on a router that was not too expensive, then there's a good chance it's CPU was still an ancient MIPS core or two, mated to vastly more modern radios. Cheap routers have only recently started moving to ARM cores with enough performance to actually do routing, traffic shaping, etc. at gigabit speeds. There were a ton of routers sold that could only get close to a gigabit of WAN to LAN throughput by offloading NAT to their built-in Ethernet switch.
Yes, it's mostly support from the Linux Kernel. The Linux kernel driver(s) need to support the Wi-Fi generation and need to support the mode(s) for use as more than a client device.
Does anybody have a recommendation for a router which is supported by OpenWrt and has a functioning VDSL2 modem? I know I could get a standalone VDSL2 terminator or use another proprietary VDSL2 router in bridge mode in front of the OpenWrt based one, but that just means that the abandoned / buggy / vulnerable firmware lives one box further in my network.
I would also be interested to connect my DSL cable directly to a device with OpenWRT on it that doesn't cost $500+. I currently have a separate device as my modem, DrayTek Vigor 166. In case someone is wondering who's still using VDSL in 2024, that would be most of Germany.
184 comments
[ 2.5 ms ] story [ 248 ms ] threadI don't want to replace ARM with RISC-V. I want ARM and RISC-V to compete with each other, micro-architectural progress to continue, and to be able to pick the best part for each task.
I agree. This is why we need to support the new open standard architecture over the established proprietary one.
P.S. you don’t get to start calling things “legacy” just because you would prefer something else. ARM is clearly at a scale right now where that’s the sweet spot for cost/performance/availability right now.
I run OpenWRT in a few locations. One of them is VM on a x86_64 fanless (SuperMicro) server hypervisor. The other is a VM on a x86_64 fanless CompuLab FitPC hypervisor.
Along with OpenWRT, those systems also run a PiHole VM (https://pi-hole.net/), and other VMs such as FreePBX (https://www.freepbx.org/).
I am interested in this, even if it is based on legacy ISA ARM, as I would rather a hacker-friendly router designed for OpenWRT.
This is relative to some consumer device off the shelf which is hostile to OpenWRT, needing trickery to just install. That is what I had in my previous location, and I would prefer this instead.
It is very possible to make a great modern implementation of a bad ISA full of legacy cruft; Zen4 is a good example of that. Intel get a participation award for trying.
That said, the VisionFive 2 is available. There's some people on the Openwrt forums working on trying to get OpenWRT to work; might not be a bad idea to reach out to them and see how far they've gotten.
The other half (wireless) could be solved by using the PCIe lanes. To do it well at scale, we'd need a new board designed for the purpose.
The Pi4A guys meant to release such a router device, but seem to have elected to do other devices instead. Shrug.
That is not what that word means. There will be more new ARM CPUs shipped next year than RISC-V CPUs. It is actively developed and improved. And this trend of people calling existing ISAs "legacy" when they're not is really annoying.
Next year is 2025 for context. I wonder what data you're supporting this forecast on.
You're asking yjftsjthsd-h to furnish data to make a slam dunk conclusion that ARM-licensed CPU designs will out-sell RISC-V.
You realize Apple Silicon is ARM, right? And 99% of all smartphones that have been sold in the last decade, and indeed in 2023, are based on ARM cores?
We are talking hundreds of millions of devices being built and sold each year, just in the phone+PC space. That's ignoring all other verticals where ARM designs can be scaled up/down to meet.
I mean, gosh, even if virtually EVERY company in the world, EXCEPT Apple, chose to drop all ARM IP tomorrow and switch to RISC-V, there'd still be a good chance the statement "There will be more new ARM CPUs shipped next year than RISC-V CPUs." would still hold true in 2025: Apple sell a lot of computers in various sizes, you know :)
I think the statement that was made was slightly different: that there would be more newly shipping ARM parts than RISC-V parts (to show that ARM is still actively developed).
Which seems very likely, but is not quite a sure thing for 2025. (And it depends upon how we count: lots of RISC-V wins inside proprietary SoCs is probably not quite what we mean, but instead new RISC-V COTS parts we can put into our designs; but if you count the former RISC-V probably looks much better).
> I think the statement that was made was slightly different: that there would be more newly shipping ARM parts than RISC-V parts (to show that ARM is still actively developed).
I actually thought about it at the time and left it ambiguous because I believe both; I believe there are and will be more ARM designs, and I also believe there are and will be more physical ARM chips manufactured.
Just out of curiosity, what does ARM designs mean here?
- New distinct processor cores available?
- New distinct parts I can buy at DigiKey and through other channels that include an ARM core?
- New distinct chips taped out using an ARM core, including vendor specific chips?
The latter is where I expect RISC-V to surge first. Probably not passing ARM in 2024, but threatening to do so. It's pretty easy to get rid of a license fee at this point unless you need extreme performance or are really picky about tooling.
ARM may not win on the first measure, either, but that's largely the vagaries of how roadmap packs into a calendar year.
There's also the whole question of whether Cortex-M counts as ARM anymore, given that modern large ARMs no longer run the Thumb instruction set (and Cortex-M only runs Thumb).
I guess we can argue semantics of what counts as "ARM", but Cortex-M sure isn't RISC-V so for the purposes of this conversation I'm inclined to unambiguously include it.
It's hard to measure how big RISC-V is for vendor-specific SOC wins. There's clearly a whole lot of momentum. Performance and all of the new things ARM does aren't necessarily too relevant if you're designing a chip that goes inside a hard drive or whatever, but a few pennies a unit to ARM might be.
Emphasis on "cores". Relative to each one of these application processor cores, how many embedded smaller cores doing specialized tasks do you think there are?
Are you aware RISC-V already has penetration there? Do you know how e.g. the popular Qualcomm SoCs have shipped a bunch of RISC-V cores for a while already?
Are you aware the companies behind popular alternatives to ARM such as Arc or MIPS have already embraced RISC-V?
In short, what makes you think that in 2025, most of these cores will be ARM?
Fair point, but the context here is your original comment:
> Great idea, but not a fan of the timing yielding a legacy (ARM) SoC.
So you're talking about the main processing cores of the SoC, the one(s) that are responsible for running the Linux kernel + OpenWRT user space, right?. Not the random other 8/16/32-bit MCUs...
My primary basis is continually trying to get a Linux-capable machine with a RISC-V CPU, which remains difficult. Look at the number of SBCs released each year for the last... I dunno, 5-10y? A bit of x86, a lot of ARM, and at the very end a single digit number of RISC-V boards. Which still are slow, expensive, or both. Even if RISC-V ships exponentially more boards each year it won't break even until after 2025. If you wish to offer data to the contrary feel free.
Now, there's a possible argument for number of non-Linux-capable chips, but I don't know how to gauge that; the... Cortex-M0? I think? Is still a popular option AIUI. Likewise, if you have actual evidence feel free to share.
(None of this should be read as dislike for RISC-V; I want to use it, but the market doesn't yet agree, and even when it does take off the competition won't magically become "legacy" at a result.)
Edit: Actually that last bit deserves more emphasis - while I believe what I wrote about numbers, it's secondary to the rest of the comment; RISC-V is great, but it in no way renders everything else "legacy" so long as they remain actively used and developed (the latter is important, but ARM continues to improve so the point stands).
It wasn't hard for me to get my VisionFive 2. It shipped within two weeks in early 2023.
But, irrational zealotry can be surprisingly powerful: Linux would not have happened without it.
So while it may seem ridiculous at times, sometimes great good (and great evil) comes from this disguised will to power, and it is part of human nature.
Management engines, millions of lines of hdd controller code, bios/firmware blobs that are basically opaque, etc are annoying and prevent me from having control over something I own.
Rightly or wrongly a lot of hope is being put into RISC-V as a way of improving the situation. The open nature of it might make it easier to break monopolies, to get control back of the hardware they own.
It's not about instruction set - its about open source. No different than the people who didn't get that Linux was a big deal because they compared OS features as if that was the primary driver.
Those hopes are obviously misplaced. The ISA isn't why your hard drive's firmware is closed. Western Digital using RISC-V isn't going to make them more willing to open up about the non-CPU parts of their chips, where their competitive advantages reside. RISC-V isn't even going to make anyone change their decision about whether to design their own CPU core or license an off the shelf core. The only real impact RISC-V will have on the industry is to slightly improve the breadth and pricing of off the shelf CPU core IP available to ASIC designers—and that doesn't have any implications for the openness of products incorporating those CPU cores.
RISC-V cannot break a dam holding back companies from open-sourcing everything when that dam is entirely imaginary.
The fundamental problem here is the IP system; even open-source is just putting lipstick on a pig. The core problem is that if you pick any particular type of device, chances are that no company is building fully open-hardware devices; it's a systemic problem. What's worse is that this is a solved problem - patents originally solved this, except for some reason firmware have copyright protection despite being a functional design, and thus they are gifted the privilege of legal protection without the responsibility of publishing documentation.
What's more, firmware's copyright isn't tuned for the electronics industry - they get protection for 70+ years, when it's duration should be the minimum duration necessary to properly incentivize producing innovative firmware. That's a variable period so I don't expect it to be an easy problem, but frankly it's not even in the ballpark.
So hypothetically, we will be legally permitted to modify the firmware of today's routers in maybe 2090 - no source code though. In fact the source code might have been lost forever, because copyright was designed for books and hasn't been properly updated before being applied to software.
Patents tend to last 20 years, which IMO is a far more reasonable duration (if your 2004 router design still isn't profitable then sucks to be you, you had a very generous window) - IMO the firmware should require source code in escrow in order to gain copyright protection, and it's copyright duration shouldn't last longer than a patent would.
See also: the tragedy of the anti-commons.
You've also posted some good unpredictable comments so I don't want to ban you, but basically anything that an account does that becomes predictable is what we're trying to avoid here.
One way to not be predictable is to include unique, relevant information in your comment, as opposed to posting something shallow. Another way is to just post on a variety of different things, without too much of a pattern.
1. They ship an excellent device. I mean, if they ship what they're describing, I'd buy it.
2. The commercial side of things corrupts and ruins the FOSS+community side of the project (see: CyanogenMod).
Hope the first one happens and the second one doesn't.
You can probably run the whole thing for $100/year of unavoidable costs (eg. Domain registration).
I think you're significantly underestimating the kind of resources a project like OpenWRT needs.
(Source: involved with CI/CD pipelines for other, smaller, FOSS projects, and those already need much more.)
Also the USB-C UART and recovery read-only bootloader is a nice touch. Really looking forward to it.
One concern is just misplaced anger because some users misunderstand what this means for OpenWRT going forward, but I hope they'll be in the minority.
> The OpenWrt project does not pay its developers,
This is actually surprising to me, but I guess the donation money isn't enough to pay developers. Would the surplus if infrastructure costs are covered go to developers or is it all going to a rainy day fund?
Prolific devs could setup a Patreon/Librepay if they'd like, but that opens up its own can of worms like false expectations/entitlement of some donators. They might prefer not to do that for that reason alone.
(1) https://www.buffalotech.com/products/airstation-highpower-n3...
I've been using (and previously contributing) to OpenWrt for almost 10 years, it's an excellent project and deserves some spotlight, I really hope this gains some traction.
I'm a big fan of OpenWRT. I switched to it after running pfSense for a lot of years. Anyone can donate to the project here: https://openwrt.org/donate
That being said, a huge portion of the consumer-oriented router brands are based on openwrt/buildroot today, so they're far from the only group guilty of benefitting from openwrt without contributing things back.
https://downloads.openwrt.org/releases/23.05.2/targets/media...
https://downloads.openwrt.org/releases/23.05.2/targets/media...
https://forum.openwrt.org/t/trouble-flashing-vanilla-openwrt...
I just got one of these. It is certainly supported! I am now running my own homebrewed build of openwrt 23.05.2I updated the gl-inet firmware to the latest 4.4.6, and then flashed vanilla openwrt 23.05.2 through the luci web interface.
I played around with the uboot flasher which takes an img file. I haven't played around enough with it yet to unpack the images to see if they are different formats or not.
It sounds like you are doing the right things. I guess check the hashes to make sure the files are intact? I haven't tested other versions or snapshots.
Did you just use the sysupgrade image from the firmware selector? How long did it take to fully flash? Yes, for the vanilla firmware, I used the sysupgrade version from the firmware selector, 23.05.2.I don't remember how long it took, but it wasn't very long. I think about 5 mins or less. I had a serial console as well, so it was easy to see that some activity was going on.
Well, I just reflashed the GL.iNet image from uboot and then flashed the OpenWrt sysupgrade image from luci again just like before so I could try to ssh and read dmesg before messing with UART and it just... worked... no idea whyI realize that 23.05 is supported on the device, but my point is that it was entirely done by individual contributors from outside of GL.iNet, not contributed by the company itself. It sucks because GL.iNet sort of built a reputation off of being the openwrt router brand, and used to be in relatively good standing, but have shifted their approach since. Now they benefit off the reputation they built previously, because of people like me who assume they're still doing that before making purchases.
Not sure I understand why this would not be exactly what one would want. (Namely, people outside the company being able to get the hardware to work with an open source OS.^1) Who wants to be stuck with a proprietary vendor OS on a router, something like Ubiquiti (a company recommended countless times on HN), where the only way to get the full features is to use their OS instead of choice of Linux/BSD installed by the buyer.
AFAICT, GL.inet software is generally no better than OpenWRT or other open source projects. It's probably terrible. Why would anyone expect otherwise. Good reason to compile OpenWRT for oneself.
The GL.inet software is probably getting worse. FWIW, one can still buy the older models. The pre-installed bootloader can be replaced. For newer models, might have to contact GL.inet. It's not clear if you are suggesting one cannot get the source to the bootloader for the router you bought, i.e., you asked GL.inet and they said no or did not respond. If that's the case, then I am interested to know.
AFAIK, people bought the older models for the hardware, e.g., GB ethernet, small form factor, and being supported by OpenWRT. GL.inet is a hardware company that lets the buyer replace the pre-installed OS with their own version; this is anticipated. That is more than many companies selling similar products.
There may be better travel router hardware available today. But being known to work with OpenWRT is an important factor for some buyers. For _some_ GL.inet models, the hardware is known to work with OpenWRT and u-boot compiled and installed by the buyer. AFAICT, the models with the Mediatek 7981 SoC are not a problem. If this is wrong, please do tell.
1. For example,
https://forum.openwrt.org/t/how-do-gl-inet-devices-become-su...
MT2500 and MT3000 will definitely get vanilla OpenWrt on them. I'm working on this. gl.inet has provided hardware and all necessary documentation (schematics, ...) to do this. Would of course be nicer if they'd even do that themselves, but that's too much to ask, I guess. It's quite different case from the SiFlower SoC where there isn't even any sourcecode for most drivers. For MT7981 everything relevant is available in sourcecode, just needed some work to go to upstream Linux and will land in OpenWrt very soon.This is certainly true. SoC vendors often base their SDK on a fixed version of OpenWrt and then add proprietary patches on top. Then sell the SoC + SDK to a device vendor that adds additional proprietary patches and sells the device.
The issue with this is that the only way to fix security issues is to back-port them to the exact kernel version the SoC used as a base, and after a year or two, they completely drop support and you're left with a device that has known security vulnerabilities you can do nothing about.
How many old routers are still in use that are used as part of a botnet?
See for example the audited financials of projects hosted by the Software in the Public Interest (SPI), where many do have tens or hundreds of thousands of dollars already https://www.spi-inc.org/treasurer/reports/202311/#index4h3
I would totally buy this device if they make it happen. My current router is about four years old and runs OpenWRT.
Are they complying with the license terms? I guess I don't understand why it would be considered a negative for them to build a product based on OpenWRT.
They do seem to be complying with the license terms, and the free portions of the software can be downloaded from the Gl.iNet website.
Most of the negatives have been covered in other comments here.
If they really want to focus on hardware and base everything on top of OpenWrt, it would be easier for them to upstream as much as possible and let the community handle updates. Even donating would be less expensive. It would be somewhat of a win-win situation IMO.
Would you care to go into why you chose it over pf/Opn Sense? Considering that you have to reinstall so it's not automatic, what makes it enough better to make the change worth your while?
I'm currently running OpnSense for my personal routing and firewalling needs, and considered OpenWRT a few weeks ago (for linux driver support, but that's another story). In the end, I changed my nic and kept opnsense.
Also, while exploring other options, I found that OpenWRT provided much higher bandwidth on the same processor/memory footprint. I was able to reduce the VM CPU and memory allocations after switching.
Finally, there were a number of features I needed that pfSense just did not support. One was IGMP snooping, another was IPv6 using a provider tunnel.
I hope OpenWRT pulls off having their own device. That would definitely be an upgrade from GL.iNet. But compared to getting a completely non-open firmware like every other GL.iNet competitor, even their versions of OpenWRT are a major step up.
There are a few of their devices that have upstream support in OpenWRT. But it is like buying any other device for running stock OpenWRT in that regard - you have to do your homework to make sure you get something compatible.
I still have OpenWRT running on a RPi4 'router' and 3 TP-Link routers as APs on my network. But still wish I could get GL.iNet's Wireguard management in Luci...
I have had a fiber line connected during the whole time and it has served me well (I haven't done much customizing on it though, I have to admit. It's just the router for my home network).
Second, why would you need something different that what routers are already doing? They are just trying to sell their own openWRT routers, the hardware has existed for a decade at or below $100, why would it be difficult for them to meet that?
https://www.amazon.com/dp/B082HH24YY/
"that this router isabeautiful (sic) example of excellent GPL/LGPL compliance"
I think about Meego/Jolla phone and tablet, Ubuntu Phone, Kobol Helios and tons of other projects that have either failed or are struggling due to market size and ecosystem.
I've been running a Turris Omnia for the last few years, which I've been fairly happy with. Network performance is about average and the platform as a whole is certainly due for an update, but stability has been great, it receives regular upgrades, and I'm happy to pay more for a project that has an open mindset. Not sure many feel the same way about commodity network hardware though.
https://www.amazon.com/NETGEAR-AC1750-Smart-Router-Gigabit/d... https://openwrt.org/toh/netgear/r6350
Here is a new router for $30 with 5 gigabit ports and usb 3.0 https://www.amazon.com/dp/B082HH24YY/
With something like a rpi that sells millions of units, that can be spread over way more units than something like this that (optimistically) gets sold to a few thousand nerds and that's it.
That's unlikely to be what was meant. It's probably m.2 2242, a shortish but "normal" drive size in the embedded space.
Notice no 20 mm width is allowed as part of the M.2 standard. The device specs are likely a typo.
As others have said, it was probably supposed to read "m.2 2242" which is physically in-between the size of the 2230 drives that the Steam Deck uses and the 2280 ones that most modern desktops and laptops use.
I'm guessing it will also be a tag from `git.openwrt.org`, from the same development and release process that continues to support numerous other consumer devices, and keep them up to date.
It might be good to clarify this, since people who've seen a lot of open source projects can imagine ways this could go bad.
I have a very favorable impression of the OpenWrt project, and I'm looking forward to this being a good thing.
2. Mediatek might not be willing to provide their WiFi SoC if you are not using their compute SoC, and Rockchip doesn't have any WiFi chips.
The rk3588 is frankly a non-starter.
There are some China-only ZTE devices that do this, but they obviously have a different order volume and scale that makes it possible. (The main SoC is replaced with a ZXIC one, a ZTE subsidiary)
* >1G internet in a mostly or exclusively wifi home
* <=1G internet + a 2.5G LAN, so that ethernet <=> wifi and ethernet<=>SSD transfers are faster
The second scenario could actually fit me right now, but my ISP is expecting to roll out multi-gigabit options later this year year.
At any rate, I agree with everyone else, I would prefer two 2.5G ports.
Seems to really limit the audience and shorten the useful life of a router to penny pinch. How about a $88 NanoPi with dual 2.5G, 4GB ram, 32GB eMMC, and wifi? Is it really worth $10 to have 1/4th the ram, 1/256th the storage, 1G instead of 2.5G and less CPU[0]?
I got similar with the faster RK3588, 8GB ram, dual 2.5 and 1G, and metal case for $120. I've been quite impressed, it's about half as fast as my xeon E3-1230 from years ago.
[0] https://www.aliexpress.us/item/3256804821229437.html
the turris devices are tinker friendly, feature rich and high quality - and not cheap.
truth be told, the aio router-server embedded thing seems very difficult because peoples expectations vary widely and the whole ids/dpi and media-server stuff gets somewhat more demanding at gigabit speeds than what unoptimized stacks can accomplish with commodity low-power hardware.
As a result, it's capable of 99% of jobs, but it's only the best choice for about 2% of them. For most things, the Omnia is tremendous overkill and nowhere near cost effective. Therefore it suffers low sales volume, and the price never comes down.
This new box might only be capable of 75% of jobs, but it should be a good cost-effective choice for quite a lot of them. It still won't be the cheapest, but it'll be reasonable, and they should sell truckloads of them.
Looks like there is some progress now for running OpenWRT on Asus RT-AX89X.
I associate openwrt with router firmware/software, so I would expect a lot of ethernet ports (more than two). Or use it as a wifi router/access point, when I only need one port. If I would want to do any networking tricks, I would fall back to a rpi/banana pi, which wouldn't do routing or wifi.
I'm only curious. I have two rpi's in my drawer doing nothing.
Longer answer:
1) providing basic networking (default gateway, connection to upstream provider)
2) basic security: firewalling + natting
3) basic network daemons, and "daemons": DNS, DHCP, IPv6 autoconf, and a nice new one: 802.11s ("network mesh": keep wifi at 5 bars by kicking people off their access point if another access point can provide a better connection)
4) more advanced networking stuff: VPN (l3vpn, l2ptp, l2ptmp, mesh vpn), cloud connections/vpns, WAN connections, redundancy (downstream and upstream, l2 and l3, ...)
5) more advanced security stuff: 802.1x, stateful firewalls, inspecting firewalls, IDS, ...
6) server networking stuff: proxy, reverse proxy, statefull firewalling, load balancing, ...
7) more advanced daemons (on network devices it's mostly proxying for redundancy and/or load balancing): File sharing, SMTP, WebDAV, Active Directory, payment protocols, ...
Now a lot of these OpenWRT can't provide, but you'd be surprised and their support for new things goes up every year.
https://www.friendlyelec.com/index.php?route=product/product...
On the other hand, they would sell it with direct support for real OpenWrt, while many other manufacturers, including FriendlyElec, often publish franken-Linux distros that force users to resort to others such as Armbian and DietPi to be sure their OS doesn't become obsolete and unsupported in a few years.
I have been looking for an open source replacement for the Elecom WRH-583BK2-S is there anything in there? It's a W65 x D35 x H20.5 (mm), dual LAN, 802.11ac router.
OpenWRT-based cheap travel routers have been a life-saver for me during my trips, specially to countries behind Iron Curtain firewalls.
I'll buy at least one as soon as it comes out.
(Asking out of total ignorance)
Back then I didn't really understand routing etc. and just used OpenWRT as plug and play. But is it actually a good alternative to the above component-based setup when just a single device is desired?
If they're able to deliver what's in the email I'll be picking one up.
https://wireless.wiki.kernel.org/en/users/Documentation/mode...
https://openwrt.org/toh/bt/homehub_v5a
Please post the links!
https://forum.openwrt.org/t/whats-your-favourite-cheap-lede-...
https://forum.openwrt.org/t/whats-your-favorite-enthusiast-l...
Best of both worlds.