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 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.
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 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.
> 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.
I use OpenWRT and what I have wished for is a configuration file as robust and simple as the one for pfSense. Version upgrades amount to a migration headache.
I've been using the attended sysupgrade and I guess I'm lucky that there's no migration needed at all. All settings are preserved.
Also, I think the configuration file is already robust enough; you can edit them using a text editor like vim or edit them using the UI or edit them using the CLI tool. I cannot think of anything to make the configuration file even more robust.
I've experienced this on OpenWrt as well. There's a backup/restore config files button but it's sort of a best-effort type of operation. If you are restoring across many versions and the config files are no longer sane, you will end up with a broken system. But the config files were restored exactly as advertised :)
Thankfully all the config files are plain text and can be manipulated however you like. It is usually not too difficult to take working config while fixing or disusing problematic files.
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 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.
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, ...)
Personally, OpenWRT doesn't really sell me nowadays as having a ton of value.
For a router, you can feasibly use an off the shelf prosumer device like Unifi, or, more compellingly, an actual robust OS like OpnSense, PfSense, Sophos or Untangle.
As for access point capability, that should really be segmented, and any off the shelf Ruckus, Aruba, Unifi etc. will always outperform the drivers available to OpenWRT. I'm a staunch advocate of an eBay ruckus 510 or 610, which will be very little in terms of cost and also your best home access point ever.
It's nice that it's open source and all, but in terms of raw performance or value-add, I don't see it. Open source for the sake of open source is... well, another discussion.
I agree that OpenWRT isn't absolutely the best, but anything you have mentioned above (prosumer devices like Unifi, or separate APs like Ruckus, Aruba) will cost far more than a simple consumer level combined router-and-AP with OpenWRT.
You probably don't see it because you are used to spending big bucks on your networking equipment whereas most people will spend $50 and then install OpenWRT to wring the most value out of it.
It's not a package deal, but router hardware for Pfsense or OpnSense, or even a Tp link or Unifi device isn't exactly breaking the bank.
It's also vastly superior enough for the Open WRT to not be worth it.
Does OpenWRT appeal to people with a low degree of knowledge, time or skill? Heck no.
The most applicable scenario I can think of is someone who is very knowledgeable and has a lot of time but very little money, but OpenWRT exclusively as a device for people who live in India or Brazil is again not super compelling to *me* as a technological package.
Though I respect conceptually that other people might have different perspectives, I live in a country with an average living standard, so I can't really share it.
> The most applicable scenario I can think of is someone who is very knowledgeable and has a lot of time but very little money
Yup. That was me as a high school student. Or rather, I wanted to be very knowledge, and did have a lot of time and very little money. OpenWRT was perfect to get started with tinkering with networking.
OpenWRT enables people to build mesh networks. I helped building some by being part of a Freifunk community and it was a great feeling - you get to tinker around with network stuff and in doing so help others (free wifi for everyone, yay!).
> As for access point capability, that should really be segmented, and any off the shelf Ruckus, Aruba, Unifi etc. will always outperform the drivers available to OpenWRT. I'm a staunch advocate of an eBay ruckus 510 or 610, which will be very little in terms of cost and also your best home access point ever.
This. Your comments about open source are relevant but IMO these days with work from home, tons of devices, larger/more well constructed homes, increased traffic for anything/everything, etc managed APs are just the way to go.
I'm a big advocate of OpenWRT but many years ago I got sick of fiddling with basic connectivity on a regular basis and dropped a few hundred dollars on a standard Unifi setup. I haven't touched or thought of my "pipes" since - to me there's nothing worse than being deep flow into a project and then having to fiddle with some router or access point because it's being flaky, dropping packets, negotiating slower link speeds, etc. It's much better than factory firmware in most cases but that's a pretty low bar.
Ubiquiti has had some controversies with data access, cloud stuff, etc but I just can't be bothered to care. For $100 x $NUM APs and a docker container to run the controller it just works.
Unifi has been truly game changing for me in terms of making wifi ethernet level reliable, predictable, and consistent - everywhere without needing to take on yet another level of deep expertise in Wifi.
I've used dd-wrt on my home routers in the past -- I bought a pre-flashed linksys router from FlashRouters, a support company affiliated with the project. The router worked fine for a year and then started dropping connections. Then, it took a lot of time for me to debug whether it was a software or hardware issues (it was hardware after all).
To replace it, I saw that Asus routers use a custom wwrt by default. And if you want to truly control it, there's an open source project that lets you adjust it more (Merlin).
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?
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.
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)
WiFi is always a problem with flashing random devices. If they can build a device that has stable WiFi with external antennas, it would be a game changer.
More generally, is there a good place to ask these questions? There are several under this post already with different requirements, and I have one too, with different requirements — I just want an edge gateway to route upstream and provide basic local network services (DCHP et al, and will turn off any radios) at low power. OpenWRT's hardware table seems not very useful; I can't, for instance, filter for at least two ethernet ports.
I have very basic requirements: a solid router that runs, and has some free memory. Everytime that I try to find a replacement that has some wide consensus, I fail to find it. My router is now 15 years old... Some people in this thread have suggested Linksys E8450/Belkin RT3200, which aren't available in EU it seems. So, it's not easy. I'll wait 15 more years probably.
Anything with the MT7986B chipset is a good choice, they support Wifi6, have a 2.5G ethernet port, have decent amounts of RAM/flash and mostl importantly have a fast enough CPU to do high speed WAN to LAN routing and firewalling.
I can make a vote against x86 in a virtualized environment like ProxMox. Setup is just way harder than it needs to be and there are a lot of gotchas.
I’m looking as well. Although now it seems like I should just buy this BPi when it is available. I would like to go back to ARM on my router… just nothing Broadcom!
What is harder? I have a setup just like that. Create VM, use open wrt image as disk Vm, configure some passthrough for the nics and press start?
Updates are as easy as other device (press button on web interface or use openwrt cli)
IMO, owrt runs best on x86 (it’s your usual Linux kernel after all) and you get the best support and performance. You also avoid a lot of all the bugs related to embedded development with custom SoC, internal switch, vlans, flash layout, possibility of brick, bootloader stuff, etc.
The Linksys E8450/Belkin RT3200 is a solid and affordable router. UBI firmware support, hardware NAT offloading and DSA support for better VLAN performance. Less than perfect WiFi range.
NVMe seems like overkill for a router of this level, but in practice getting M.2 drives is a lot easier/cheaper than eMMC. And while microSD can work, it doesn't have the reliability, write durability, and random IO of a 'real' drive.
I might be interested, depending on the power consumption, and on whether or not it has enough resources to run a DNS server (for reasons of ad blocking mostly). Don't particularly care about the price tag, would easily pay twice the target price.
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.
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)
Would absolutely love to buy this and throw OpenBSD on it. Not all proposed hw appears to be supported yet but if this gains traction then that might be enough of a catalyst.
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.
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.
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.
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.
I looked at the specs. It's a BananaPi R3 mini with stuff added that nobody will ever use. I can't really find a use for such a device, unless you're the maintainer for some kernel driver used on that board.
Compared to an ordinary router:
1) There's a bit more powerful CPU, barely enough for TOR or wireguard VPN. Doesn't say anything about hardware crypto.
2) There's 1 GB RAM, way too much for basic routing, barely enough for TOR, barely enough to run a webserver, but not both.
3) There's NVME storage as an option, but NVME is too small, too expensive, and MUCH too fast for a NAS with that kind of networking, and there's no USB3 or eSATA to connect external storage such as a large HDD or a DAS.
4) I assume that the wifi chip (only one?) is soldered. If the driver ever becomes unmaintained, like it happend with mwlwifi, you throw the router into the garbage.
5) It doesn't even have a network switch.
6) They plan to load it with various features (serial, USB debug, JTAG (ffs! why??)) that only devs will ever use, and only until they get it booting. No use for all that once it boots reliably.
7) Modbus? Who uses that!? I want mPCIe, GPIOs, I2c, SPI, serial (other than the debug port), RS485, you know... actually useful stuff!
8) And there's RTC on a device that 99.9999% of users will connect to the internet. Why? For the rare situations when it boots after a power failure before the ISP network is up? If it had SPI/I2c out, there are Raspberry Pi RTC modules that could be added for $1.
9) The price: 100$ is waaaay to much for something that's only a micro-router. GL-MT3000 is in the same price category and has USB3.
My ideal router would have:
- 2 GHz 4 core armv8 CPU, or at least 2 core armv7+vfpv3
3: As a consumer, NVME drives are an off the shelf easy to source item. All of the storage cases you specify are better served by a 'full server', even if that is a desktop device running 'x86_64' OpenWRT.
8: RTC is SURPRISINGLY very important for E.G. Initial TLS / HTTPS connections and bootstrapping secure connections. It's also a serious quality of life aspect that doesn't cost that much to add. Surely you've seen the hell caused by Microsoft's attempts to fix this problem wreaking havoc with connection failures.
5: I suspect that was more to fit the form factor of an existing off the shelf case, and dangling a dumb-switch off the internal port is a reasonable option. This is annoying but I understand the reasons and tradeoffs.
I see using this device as a router for E.G. grandma's / friend / other family. Where someone tech literate buys the thing that does 99.9% of the desired work for a lot less headache and that you know will see updates because it's supported from day 0 by OpenWRT / the community.
Wifi 6E, with the upper band frequencies, might be enough to convince me to get it too.
3: True. x86 would be better, but that doesn't mean that NVME is of any use on a router like that. Like I said: it's too fast and too expensive at any size compared to alternatives. And not easy removable.
8: I'm not aware of any problems. Why would TLS and HTTPS not work? AFAIK, when NTP is not yet up, OpenWrt sets system time to the timestamp of the most recent saved file. That is good enough not to run into "certificate not yet valid" situations. And what HTTPS and TLS are you talking about? DNS over <something> won't work until WAN is up. When WAN is up, NTP is up too.
5: I don't. What good is a slow cheap router if I need another device next to it? Might as well put an old laptop/desktop as router instead.
Lots of routers are supported by OpenWrt, until they aren't. I already mentioned mwlwifi - they were the best routers, most recommended, until that driver was abandoned. Soldered wifi from another manufacturer won't change the situation. Works today; crashes tomorrow.
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?
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...
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.
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!
> 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.
> 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.
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).
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.
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.
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.
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.
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.
I use a Beryl as a travel router (connects to Hotel or Plane Wifi, you authenticate the captive portal, then it creates a separate wifi network and opens a VPN tunnel). It's such a great little device for less than $100 and allows me to keep things a bit more secure, avoid config for each device, and on planes it allows us to split a higher capacity plan. All OpenWRT
While this and other GL.iNet devices use OpenWRT (with their own custom UI/frontend), they don't contribute to the OpenWRT project in terms of code or funding, many of their devices are incompatible with mainline OpenWRT releases, and software updates are few and far between.
I have one of these myself, they're handy devices, but I wouldn't go and recommend them as good OpenWRT devices.
I would love to buy into OpenWRT but I need a mesh router due to the size of my house. Do you know of the recommended hardware? I couldn't find anything the last time I searched a year or two ago
Since the demise of Soekris and PC Engines, I don't know of good alternatives. I'd like to be excited about newer ARM-based, power sipping routers- but which ones aren't so cheaply made? The aformentioned companies hit that sweet spot- a 2-3x cost premium for industrial quality and an open approach. They were devoted to hardware and wasted no energy on branded forks of OpenWRT.
I'm curious to try some Teltonika products like the RUT series. They seem sparsely documented on the OpenWRT wiki, though.
Curious to hear any Soekris/PC Engines fans experience with newer stuff.
The $100 price tag is much less important to me than long term production runs. I hope they take a page from the pcengines playbook, and arrange to build this with minimal changes over a 5-10 year period.
For instance, I can imagine them holding all specs constant except that they ship a new wifi radio every 2-3 years.
This would allow other open source projects to target it and be rock solid. For instance, my pc engines openbsd router is something like 8 years old and has never crashed.
I’d happily pay a $50-100 premium to get a brand new board that’s fast enough, but that had all the bugs worked out the last few years.
It looks like at least one of the radios is on the same SoC as the CPU, Ethernet, etc., so swapping out just the radio every few years isn't quite feasible. Such highly-integrated WiFi SoCs are pretty standard for this price range, and getting a processor with enough PCIe and Ethernet to use only external MAC+PHY solutions is a lot more expensive.
The MT7976C they're including is a 3x3 WiFi 6 chip, and you can buy them as a standalone module for ~ $25. I think the idea is that it's providing the access point radio.
That's the part I'd suggest swapping out every few years. That might mean people are stuck with older bluetooth or a low performance WiFi radio or whatever on the SoC, but that won't impact performance much. (In the worst case, they could just disable the SoC radios to prevent RF interference with the "real" radio.)
I think this is intended to offer simultaneous dual-band (2.4GHz and 5GHz) using two separate radios, as all decent APs for over a decade have done. The SoC provides one of the two radios, and the second is connected over PCIe. Whether your 2.4GHz or 5GHz radio more badly needs an upgrade in a few years can be hard to predict.
I'm reasonably sure this line of chips is designed to be the only active radio in an access point:
> Filogic 830 packs a wide variety of features into a compact, ultra-low power 12nm SoC, allowing customers to design differentiated solutions for routers, access points and mesh systems. The SoC integrates four Arm Cortex-A53 processors operating at up to 2GHz per core for up to +18,000 DMIPs processing power, dual 4x4 Wi-Fi 6/6E for up to 6Gbps connectivity, two 2.5 Gigabit Ethernet interfaces and a host of peripheral interfaces. Filogic 830’s built-in hardware acceleration engines for Wi-Fi offloading and networking enable faster and more reliable connectivity. In addition, the chipset also supports MediaTek FastPath™ technology for low latency applications such as gaming and AR/VR.
My reading of that is that the ARMs are there for software defined networking tasks, and not to run the router OS. I could be wrong. However, the OpenWRT spec lists this chip as a network adapter, not as the main SoC.
I think the "Filogic 820" branding may actually apply to the combination of the MT7981B SoC and the MT7976C NIC. https://wikidevi.wi-cat.ru/MediaTek seems to have actual detailed specs for these chips. It looks like the MT7981B is what has the ARM Cortex-A53 cores to run Linux, Ethernet, PCIe, and a 2x3:2 radio. The MT7976C is just a NIC with no application processor cores, but it has both a 2.4GHz and 5/6GHz radio. A NIC with two separate radios seems to be a relatively recent development, probably spurred by increased demand for tri-band routers after the opening of the 6GHz band.
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.
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.
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.
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'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.
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 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'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.
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.