The OpenWrt One system
The OpenWrt One was designed to be a functional network router that would
serve as a useful tool for the development of OpenWrt itself. To that end,
the hope was to create a device that was entirely supported by upstream
free software, and which was as unbrickable as it could be. The developers
involved concluded that the Banana
Pi boards were already reasonably close to those objectives, so that
was the chosen starting point. Banana Pi is also the manufacturer of the
board that resulted.
The OpenWrt One comes with a two-core Arm Cortex-A53 processor, 1GB of RAM, and 256MB of NAND flash memory. There is also a separate, read-only 16MB NOR flash array in the device. Normally, the OpenWrt One will boot and run from the NAND flash, but there is a small switch in the back that will cause it to boot from the NOR instead. This is a bricking-resistance feature; should a software load break the device, it can be recovered by booting from NOR and flashing a new image into the NAND array.
The device only comes with two Ethernet ports, one configured by default to talk to an upstream router. That choice raised a few eyebrows, since a router can normally be expected to have more ports; in an FAQ posting in January, John Crispin defended that choice this way:
We didn't want to impose additional complexity and costs by including an external managed switch IC. One port is 1GBit/s capable, while the other features a speed up to 2.5GBit/s. This is a limitation of the chosen SoC.
The router has 2.4GHz and 5GHz WiFi radios and three antennas. There is a USB 2.0 port on the front. Within the box, there is a mikroBUS connector for miscellaneous peripheral devices and an M.2 PCIe connector for the attachment of a solid-state drive. The space for M.2 cards is limited to the 2242 or 2230 formats, meaning that it allows the addition of up to 2TB of relatively fast storage with currently available drives. That, in turn, would make it possible to use the router as a network-attached storage server, or to run a more traditional Linux distribution on it.
The OpenWrt one arrived with no documentation whatsoever. Perhaps
surprisingly for a device shipped by the SFC, it also lacked the required
written offer to provide source for the GPL-licensed software contained
within — not that said source is difficult to find. [Correction:
the offer is there, printed on the outside of the box. I missed that, and
apologize for the mistake.] There was no power
supply provided; the user needs to supply a USB-C charger or power over
Ethernet. It draws about three watts when operating.
The device had a minimal OpenWrt snapshot installed. Evidently, it was not the intended image and did not work properly; it would boot and allow logins via SSH, but lacked the ability to install the LuCI web interface. That made life difficult for those of us who, having never taken the time to fully understand OpenWrt's unique package-management and configuration tools, tend to lean hard on LuCI. That, in turn, led to an early exercise of the NOR-flash recovery mechanism, described on this page, to flash a new image. The ritual is a bit cumbersome, involving holding a front-panel button down while connecting power to the rear. But, then, completely reflashing a device should not be something one can do accidentally.
After booting into the new image, the One behaved like any other OpenWrt router. It came up running a 6.6.50 kernel and with LuCI installed; with just a bit of configuration, it was sitting on the local network and providing WiFi service. Nothing exciting to report. That is the thing about working hardware; it just quietly does what is expected of it.
What could be more interesting is seeing this router get into the hands of
developers and enthusiasts who will use it to make OpenWrt (and other
small-system distributions) better. The combination of free software
(with the exception, seemingly, of the firmware blob loaded into the WiFi
adapter) and brick-proof hardware should make the OpenWrt One a relatively
easy and pleasant device to develop for. That will, hopefully, encourage
more developers to join the project and make the system better for
everybody.
Getting there, though, will require some significant documentation improvements. The device lacks even the usual "getting started" page, much less more detailed information on how to connect it to the network or what the three LEDs mean. A nice tutorial on how to build a custom image for this device would be welcome. OpenWrt as a whole has reasonably complete (if sometimes hard to navigate) documentation, so presumably these gaps will be filled over time.
Given the wide range of devices that OpenWrt can run on, the addition of one more might seem like a drop in the bucket. But most of those systems were designed to run something else, even if it is often OpenWrt with a proprietary interface grafted on top, and replacing the software is not always easy or risk-free. A device that was designed to run OpenWrt from the beginning, without limiting the user's freedom, is a welcome addition and a suitable present to the OpenWrt project as it celebrates 20 years of development.
[The OpenWrt One is expected to be generally available by the end of
November. The price of each system will include an (unspecified) donation
to the OpenWrt project. Schematics and data sheets for
the device are also available.]
Posted Nov 4, 2024 16:20 UTC (Mon)
by Trelane (subscriber, #56877)
[Link] (6 responses)
TBH, I need such a switch much more urgently than another good wireless router. There are a bunch of ones that run OpenWRT quite nicely already, but few, if any, switches capable of OpenWRT. (If I'm wrong, I look forward to finding out! I really need 2.5+ Gbps ethernet vlan capable switches running OpenWRT! )
Posted Nov 4, 2024 16:44 UTC (Mon)
by paulj (subscriber, #341)
[Link] (5 responses)
E.g. the market leader in the mid-range+, Broadcom, ship a Linux switch OS in their dev kit to vendors I think. Unfortunately, Broadcom are also utter ba*ds on any kind of open support - inc docs. You can however buy "white box" switches that give you full access to the Linux host, and let you manage them as Linux machines and/or run OpenWRT - even if you have to tolerate a huge binary-blob of a Broadcom driver (and sometimes a binary blob user-space bit too, depending on the approach).
However, the market leader in the lower-end, RealTek, either are a bit better and/or the chips are easier to rev-eng (simpler?) and there is some open-source support now for their switch chips. Some of these switches are fairly capable, inc 10G:
https://svanheule.net/switches
Posted Nov 5, 2024 13:24 UTC (Tue)
by Trelane (subscriber, #56877)
[Link] (4 responses)
Posted Nov 5, 2024 13:51 UTC (Tue)
by paulj (subscriber, #341)
[Link] (3 responses)
If you need the performance (or L3 features) of the Broadcom chips, I guess you're stuck and have to accept big (and sometimes buggy) blobs. I don't have a specific recommendation there. You are paying a lot more, so I assume most are good quality. I have played with Edgecore Networks ones a long time ago - they worked. And Edgecore's have been OEM resold by some very large "enterprise" hardware companies. The likes of Foxconn, Lanner, Quanta and Celestica are OEMs for a number of western brands - and some of those also are also the manufacturers for the "own design" network switches of FAANGs.
You kind of have to do your research if you need one of those higher-end switches: What software stack do you want to run on your higher-end "white box" switch, and then see which switches they support.
For the lower-end L2 RealTeks, they're cheap enough you can just buy one or two and experiment.
Posted Nov 6, 2024 16:18 UTC (Wed)
by Trelane (subscriber, #56877)
[Link] (2 responses)
Posted Nov 6, 2024 18:12 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
Have a look around https://downloads.openwrt.org/releases/23.05.5/targets/re... to see what's there.
I don't know how well it works, havn't tried myself yet. On my TODO list to buy one of the ones documented as reasonably well supported.
Posted Dec 2, 2024 12:43 UTC (Mon)
by tim_small (guest, #35401)
[Link]
GPL sources aren't available (despite requests!) but nevertheless many models have mainline or snapshot OpenWrt support.
The PoE models aren't fully supported (e.g. fan speed control is lacking so the fans default to full-speed and the stock fans are noisy on full power), but development is active and ongoing. Some models (non PoE up to 24 port) and the smaller PoE models do not have fans so that's not a problem. Link aggregation doesn't yet work on any Realteks in OpenWrt as far as I know.
Locally the 24 port (+ 4x SFP) non-PoE version is available used from about £20 (€25 / $25).
Posted Nov 4, 2024 16:59 UTC (Mon)
by Sesse (subscriber, #53779)
[Link] (4 responses)
Posted Nov 4, 2024 17:07 UTC (Mon)
by corbet (editor, #1)
[Link]
Posted Nov 13, 2024 9:56 UTC (Wed)
by danieldk (subscriber, #27876)
[Link] (2 responses)
The OpenWrt One uses a Mediatek Filogic 820 (I think), which generally use NPUs that are really well-supported by the kernel.
To give an example, I have a router that uses Filogic 830 and it has no issue at all doing PPPoE, NAT, and firewalling at line speed (2.5Gbit), while the CPU cores are idle. It even seems to do fq-codel in hardware and gives me a buffer bloat rating of A.
tl;dr: the CPU cores are not for processing packets, but for running the web interface.
Posted Nov 13, 2024 10:59 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
I can't find programming docs for the PSE in the MediaTek engine, but OpenWRT patches I can find for stuff like "Wireless Ethernet Dispatch (offload of wifi packets to PSE) look to be the typical programming of tables for fixed-function pipeline.
Generally, where you see NPUs, you'll still see a fixed-function packet processing pipeline. Cause the latter handles the common case much faster and with lower latency than NPUs. The NPUs will be there to accelerate the "slow path" - allowing uncommon case packets to be processed faster than entirely on CPU.
Posted Nov 13, 2024 19:51 UTC (Wed)
by danieldk (subscriber, #27876)
[Link]
Posted Nov 4, 2024 17:17 UTC (Mon)
by shemminger (subscriber, #5739)
[Link] (7 responses)
Posted Nov 5, 2024 2:18 UTC (Tue)
by mtaht (subscriber, #11087)
[Link] (4 responses)
Posted Nov 5, 2024 6:03 UTC (Tue)
by DemiMarie (subscriber, #164188)
[Link] (3 responses)
Posted Nov 5, 2024 10:38 UTC (Tue)
by Sesse (subscriber, #53779)
[Link] (2 responses)
Posted Nov 5, 2024 15:43 UTC (Tue)
by mtaht (subscriber, #11087)
[Link] (1 responses)
If you are willing to give up pure fq and instead just try to schedule per core the complexity goes down.
Posted Jan 19, 2025 4:59 UTC (Sun)
by Simon80 (subscriber, #50887)
[Link]
Posted Nov 5, 2024 3:58 UTC (Tue)
by jalla (guest, #101175)
[Link] (1 responses)
If you're looking for something close to open, check-out odroid (which, is also ancient at this point on arm).
Posted Nov 6, 2024 8:01 UTC (Wed)
by parametricpoly (subscriber, #143903)
[Link]
Posted Nov 4, 2024 18:06 UTC (Mon)
by bkuhn (subscriber, #58642)
[Link] (13 responses)
Jon wrote in article above:
One port is fine
One port is fine
One port is fine
One port is fine
One port is fine
One port is fine
OpenWrt switches
Price?
There are preorders available at $99 from a certain ecommerce site that I prefer not to link to. I am informed that the price will be lower at general availability, but I don't know by how much.
Price?
Price?
Price?
Price?
Not enough CPU
A typical Armv8 Cortex A53 can't run CAKE at 1G bit. It tops out at about 700Mbit for me.
Not enough CPU
CAKE single-threaded?
CAKE single-threaded?
CAKE single-threaded?
CAKE single-threaded?
Not enough CPU
Not enough CPU
“Offer for Source” is quite prominent on the box and also printed on PCB!
The OpenWrt one arrived with no documentation whatsoever. Perhaps surprisingly for a device shipped by the SFC, it also lacked the required written offer to provide source for the GPL-licensed software contained within — not that said source is difficult to find. [Correction: the offer is there, printed on the outside of the box. I missed that, and apologize for the mistake.]
Thanks for the quick correction, Jon. Of course, we at SFC went to great lengths to make sure that we are fully in compliance with the GPL and other relevant licenses. We're very proud of the work that Denver Gingerich and the OpenWrt team (John Crispin in particular) did to make this product happen!
In case folks want to see what the offer looks like, we've posted an image of the box. Also, the “offer for source” is actually imprinted on the PCB itself — that way, if the device is separted from its box, the person with the device in their hand still has the offer, and will see it if they open the case to do hardware hacking on the device.
Posted Nov 4, 2024 20:12 UTC (Mon)
by ossguy (guest, #82918)
[Link] (12 responses)
The unit reviewed above is a Test Run unit, so there are several changes you can expect in the final version, including a bundled power adapter, and no need to reflash the device — it will ship with the standard image (including LuCI) you'd expect from OpenWrt. Also, we'll fix typos on the box (such as the missing newline). I did also see this note in the article: Probably that was written before Jon corrected his error regarding the offer for source code. The source code (which is downloadable today — but we'll of course send it to you in a “medium customarily used for software interchange” by mail if you prefer) includes all the instructions needed to make modifications to the image and install those modifications on the device (i.e., it includes all “the scripts used to control compilation and installation of the executable[s]” — as all compliant source releases must when a device uses copylefted programs). Specifically, you will find these in the Lastly, regardless of the sticker price you pay, a US$10 donation will go to the OpenWrt earmarked fund at Software Freedom Conservancy for every unit sold.
Posted Nov 5, 2024 19:59 UTC (Tue)
by comex (subscriber, #71521)
[Link] (11 responses)
I am partly trolling, partly serious. I'm trolling in the sense I'm well aware that this requirement is routinely ignored across all the licenses it appears in. I'm serious in the sense that, if you're making a point of dotting i's and crossing t's regarding license compliance, I feel like you ought to have an answer to this question.
I'm also aware that the Git history is publicly available on GitHub. The tarballs are even labeled with the corresponding commit hashes. So for all practical purposes, nothing is missing. But the page you linked, https://one.openwrt.org/sources/, seems to be portraying the tarballs as independently satisfying the GPL's source distribution requirements, so my question is about how they do so, not about whether the requirements are satisfied some other way.
I'm mainly referring to the top-level scripts and other OpenWrt-specific code that is licensed under GPLv2, not the third-party projects whose tarballs are included. OpenWrt does not appear to use copyright assignment, but instead relies on a peer-to-peer licensing model, judging by the top-level COPYING file's statement that "All contributions to OpenWrt are subject to this COPYING file." In other words, each contributor who submits a change is distributing a "modified version" to everyone else, triggering the requirement for "prominent notices". There are no such notices "carr[ied]" in the files themselves, as the license seems to have originally envisioned. But I've seen it argued that Git history counts as sufficient notice, since it indicates who changed which files and when. However, that wouldn't apply to tarballs that lack Git history.
Can you get away without distributing history because the original changes would have been submitted with history, and the later redistribution into a tarball is a separate event?
(As for third-party projects, I see that OpenWrt-specific changes are already cleanly separated out into patch files, and some of the patch files contain From: and Date: lines. However, others don't. The tarball's date metadata doesn't help here: it lists the same date for all files, presumably the date when the tarball was created as opposed to when the patches were written.)
Posted Nov 5, 2024 21:17 UTC (Tue)
by bkuhn (subscriber, #58642)
[Link] (10 responses)
🙄 … Yes, you are. I wrote on this issue extensively 13 years ago:
https://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html
The text of GPLv2 hasn't changed in the meantime — to my knowledge.
Posted Nov 6, 2024 10:33 UTC (Wed)
by paulj (subscriber, #341)
[Link] (9 responses)
The customary practices of the software industry have changed greatly since the GPL was written.
Personally, I'd love to see a court come along and kick the backside of the various people who insist that the GPL distribution requirements are set in stone, and hence a tarball suffice. It's as daft as arguing that because mailing out tape with a tar file was acceptable in the 80s that it's acceptable today.
Posted Nov 6, 2024 12:34 UTC (Wed)
by pizza (subscriber, #46)
[Link] (5 responses)
The tarball _is_ the "complete corresponding source code."
The git commit history is _not_.
End of story.
Posted Nov 6, 2024 12:37 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Posted Nov 6, 2024 13:14 UTC (Wed)
by paulj (subscriber, #341)
[Link] (3 responses)
1. A git repo, that you and your organisation use for working on
2. A tarball made from 1 with git archive
And you try tell me that the /latter/ is the preferred form for you or anyone else, then I say you are simply lying (possibly cause your business model depends on it).
Posted Nov 6, 2024 13:31 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
I'm going to take the FSF's word over yours.
Or are you accusing the FSF of violating their own licenses, possibly because "their business model" depends on it?
Posted Nov 6, 2024 13:43 UTC (Wed)
by paulj (subscriber, #341)
[Link] (1 responses)
Further, again, it's explicitly defined in a way that allows the meaning to be context (including temporal) specific.
Posted Nov 6, 2024 16:04 UTC (Wed)
by pizza (subscriber, #46)
[Link]
...Or are you arguing that everyone should be forced to publish every private intermediate draft or edit, even if there was no external distribution of anything (binaries or source)? Is git squashing and rebasing now verboten?
[1] I make a minor change to Linux to support my hardware. Should I also have to distribute all 3GB of Linux's upstream git history? What about upstream's pre-git history all the way back to 1991? If the answer is different, why,? What's the cutoff? one version? Five versions? One year of history? five years of history? What if I don't use *your* preferred VCS at all? Can I comply by supplying a SoS, Perforce, or Bitkeeper repository (that you may not be able to legally access because you worked on a competing VCS in violation of the Bitkeeper license)?
Posted Nov 6, 2024 15:55 UTC (Wed)
by ballombe (subscriber, #9523)
[Link]
SCCS (1973) <https://en.wikipedia.org/wiki/Source_Code_Control_System>
So at the time the GPL v2 was drafted, version control system were already in use by professional developers,
Posted Nov 7, 2024 12:49 UTC (Thu)
by bkuhn (subscriber, #58642)
[Link]
GPLv2 refers to “customarily” only in GPLv2§3(a). Indeed …
… no one (particularly, not me) was arguing in this thread that 8mm tape (or other software delivery methods common in the 1980s and 1990s) are still “customarily used for software interchange”.
We were talking about GPLv2§2(a), not GPLv2§3(a).
And, FWIW, I've been doing GPL enforcement and compliance as my primary work activity since 1997, and I have never seen anyone argue before that you have to interpret GPLv2§2(a) using the language in GPLv2§3(a). I'm open-minded to it, as it is common for one part of an agreement to influence interpretation of other parts, but there are lot of dots to connect to make a successful argument that the wording of GPLv2§3(a) somehow influences GPLv2§2(a) — and you've not connected those dots.
Posted Jan 19, 2025 9:55 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
Well, If I can't be assed to use a VCS (some people don't), and my standard backup practice is a tarball (ie I'm a dinosaur, which is true but in my case not THAT true), then a tarball is the only choice.
The end user does not get to dictate to the developer what working practices they use. If the developer says "here is a copy of my working directory as backed up when I gave you the binary", then that's what you get!
And if the developer says "I've only got mobile pay-as-you-go internet and posting a CD is cheaper" then you have to negotiate a price for sending it by email or whatever.
At the end of the day, pretty much the only come-back the user has against the developer is "you're not allowed to treat ME DIFFERENTLY with the INTENT of causing pain".
Cheers,
Posted Nov 4, 2024 18:51 UTC (Mon)
by sub2LWN (subscriber, #134200)
[Link] (1 responses)
At any rate, this looks very maintainable compared to the molded plastic contraptions in a similar price bracket at big box stores.
IMO it'd be nice if future models begin to settle into the same form factor: the old Linksys models which were designed to stack on each other were a very optimistic choice vs how the market has evolved so far.
Posted Nov 4, 2024 20:35 UTC (Mon)
by rknight (subscriber, #26792)
[Link]
Posted Nov 4, 2024 20:26 UTC (Mon)
by cen (subscriber, #170575)
[Link]
Posted Nov 5, 2024 12:38 UTC (Tue)
by dvrabel (subscriber, #9500)
[Link] (3 responses)
Posted Nov 5, 2024 14:48 UTC (Tue)
by corbet (editor, #1)
[Link] (2 responses)
Posted Nov 5, 2024 19:45 UTC (Tue)
by dvrabel (subscriber, #9500)
[Link] (1 responses)
I don't see any licensing information for the provided schematics, the kicad project file is missing, and there are no PCB design files.
Posted Nov 6, 2024 7:46 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
What licence needs to be provided? A copyright licence is irrelevant, as is a trademark licence. The problem is patents, which if they don't have any, they can't licence them.
And - genuine question - did they use kicad? Do they even HAVE a kicad file?
And lastly, is this highlighting the difference between "Open" and "Free"? What you're demanding seems to me to fall clearly within the realms of "Free", which is not "permitted to freely create and distribute derivative works".
"Open" is "you are free to copy my work output". "Free" is "I am obligated to provide my work source". This is clearly "Open".
Cheers,
Posted Nov 7, 2024 9:55 UTC (Thu)
by NRArnot (subscriber, #3033)
[Link] (3 responses)
Why am I wrong to think this may be too little too late?
Posted Nov 7, 2024 12:15 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
Fully integrated and ready to go?
Much lower power consumption?
Wifi that doesn't suck?
Actual support?
> They usually have 2 x 2.5Gbps Ethernet,
Details matter; I have one of these mini PCs that has 2.5Gbps Ethernet ports on PCIe links that max out at 2Gbps (according to Linux's kernel output)
Posted Nov 7, 2024 18:26 UTC (Thu)
by rknight (subscriber, #26792)
[Link] (1 responses)
>Much lower power consumption?
>Wifi that doesn't suck?
>Actual support?
Not to mention both Packet Switch Engine and Packet Process Engine integrated into the SoC which most of those cheap mini-PCs are missing.
Posted Nov 8, 2024 10:55 UTC (Fri)
by paulj (subscriber, #341)
[Link]
If you don't like the physical design of the OpenWRT One box, you could buy one of those others - and just make a donation to OpenWRT.
Posted Nov 8, 2024 16:49 UTC (Fri)
by carlosrodfern (subscriber, #166486)
[Link]
Posted Nov 29, 2024 21:05 UTC (Fri)
by ossguy (guest, #82918)
[Link]
https://sfconservancy.org/news/2024/nov/29/openwrt-one-wi...
I also posted a brief analysis of the OpenWrt One source release at the following link (it seems there was some interest in the source code based on this LWN article and related discussions):
https://sfconservancy.org/usethesource/candidate/openwrt-...
Build/Install instructions are in the source code (of course)!
A nice tutorial on how to build a custom image for this device would be welcome.
how_to_compile_and_install.txt file
. Of course, you can also build and modify OpenWrt using the usual repositories instead — that is to say, a stock build of SNAPSHOT (or the upcoming release) will also work fine.Prominent notices
GPLv2§2(a) does not say what you think it says
GPLv2§2(a) does not say what you think it says
GPLv2§2(a) does not say what you think it says
GPLv2§2(a) does not say what you think it says
GPLv2§2(a) does not say what you think it says
GPLv2§2(a) does not say what you think it says
GPLv2§2(a) does not say what you think it says
GPLv2§2(a) does not say what you think it says
[2] Overly pedantic folks can argue that one needs to include "prominent notices" saying the date of your modifications (GPLv3 5(a) ) -- But you don't have to enumerate your specific changes, and the "date" can just be when you publicly published them in the modified work. Still, you can achieve both by your tarball'd git repo having two commits; the first being the unmodified upstream source code, and the second containing all of your changes.
GPLv2§2(a) does not say what you think it says
RCS (1982) <https://en.wikipedia.org/wiki/Revision_Control_System>
CVS (1986) <https://en.wikipedia.org/wiki/Concurrent_Versions_System>
GPLv2 (1991)
including by the GNU project (which released RCS as GPLv1 before GLPv2 was published).
GPLv2§2(a) does not say what you think it says
…
> It's as daft as arguing that because mailing out tape with a tar file was acceptable in the 80s that it's acceptable today.
GPLv2§2(a) does not say what you think it says
Wol
M.2 PCIe Possibilities?
M.2 PCIe Possibilities?
WiFi
Open Hardware?
Open in what sense? The designs have been posted under free licenses and are linked in the article; were you thinking of something else?
Open Hardware?
Open Hardware?
Open Hardware?
Wol
I'm wondering why?
I'm wondering why?
I'm wondering why?
>Fully integrated and ready to go?
I'm wondering why?
Thank you
Production version of OpenWrt One released