The OpenWrt One system

By Jonathan Corbet
November 4, 2024

OpenWrt is, despite its relatively low profile, one of our community's most important distributions; it runs untold numbers of network routers and has served as the base on which a lot of network-oriented development (including the bufferbloat-reduction work) has been done. At the beginning of 2024, a few members of the project announced a plan to design and produce a router device specifically designed to run OpenWrt. This device, dubbed the "OpenWrt One", is now becoming available; the kind folks at the Software Freedom Conservancy were kind enough to ship one to LWN, where the desire to play with a new toy is never lacking.

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.]

to post comments

One port is fine

Posted Nov 4, 2024 16:20 UTC (Mon) by Trelane (subscriber, #56877) [Link] (6 responses)

Provided there is a managed switch we could use in combination with it. Hopefully that (with 1. 2.5, and 10Gbps wired Ethernet) is coming eventually.

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! )

One port is fine

Posted Nov 4, 2024 16:44 UTC (Mon) by paulj (subscriber, #341) [Link] (5 responses)

Many (or... pretty much /all/ these days?) of them already run Linux.

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

One port is fine

Posted Nov 5, 2024 13:24 UTC (Tue) by Trelane (subscriber, #56877) [Link] (4 responses)

Do you have some examples of white box switches that are decent?

One port is fine

Posted Nov 5, 2024 13:51 UTC (Tue) by paulj (subscriber, #341) [Link] (3 responses)

Personally, for my uses, I'd avoid the binary-blob Broadcom switches. I'd go for a decent RealTeks.

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.

One port is fine

Posted Nov 6, 2024 16:18 UTC (Wed) by Trelane (subscriber, #56877) [Link] (2 responses)

Hmm. The RealTek options are compelling. I'm a bit hesitant to run sone random code on it though, rather than e.g OpenWRT. Is this a well established project or such?

One port is fine

Posted Nov 6, 2024 18:12 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Well, it's a project to add device support within OpenWRT. The "upstream" the patches are going to is OpenWRT. You can download images from OpenWRT for those that are upstream. Though, as per the project page, a lot of devices are still far from fully supported! Caveat Emptor.

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.

OpenWrt switches

Posted Dec 2, 2024 12:43 UTC (Mon) by tim_small (guest, #35401) [Link]

The HPE or HP 1920 series are some cheap options for used gigabit switches with external console ports. These were produced by a Chinese part-owned HP subsidiary "H3C" which they acquired when they purchased 3Com and sold by HP and later HPE.

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).

Price?

Posted Nov 4, 2024 16:59 UTC (Mon) by Sesse (subscriber, #53779) [Link] (4 responses)

So, what will it cost if you want to buy one? The specs look seriously anemic (e.g. 2012-era low-end CPU), so is this intended as an expensive gadget for free-software-only hardliners or more of an entry-level device?

Price?

Posted Nov 4, 2024 17:07 UTC (Mon) by corbet (editor, #1) [Link]

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?

Posted Nov 13, 2024 9:56 UTC (Wed) by danieldk (guest, #27876) [Link] (2 responses)

I agree that Cortex-A53 are somewhat anemic. *However*, the performance of these routers is mostly determined by the capability of their network processing units (confusingly also called NPUs). Good NPUs can offload PPPoE, NAT, etc., so in practice these routers will be near-idle when it comes to regular cores during high network load because NPUs are doing the work.

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.

Price?

Posted Nov 13, 2024 10:59 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

NPUs are generally a different thing to the common forwarding logic in switch ASICs / SoCs. NPUs are programmable logic that are aimed at processing data as it streams through, applying transforms to the data (possibly with the aid of other fixed blocks of logic, e.g. cryptographic functions). The switching ASICs and the switching blocks in SoCs in these kinds of AP/routers are generally fixed-function pipelines, configured via tables (mostly). I.e. you setup lookup tables (e.g. enable or disable whatever features, and then create entries in the tables that control those features) - and the fixed-function pipeline applies its logic to packets, guided by lookups in tables. The logic is not generally programmable - it's not an NPU.

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.

Price?

Posted Nov 13, 2024 19:51 UTC (Wed) by danieldk (guest, #27876) [Link]

I just wanted to say 'thank you' for this reply. For someone who just dabbled a bit in OpenWrt and OPNsense, it's very insightful. I guess I was slightly misled because some vendors call both types of offloading together 'NPU' in their marketing. At any rate, I hope the general point was clear though, that even with old Cortex cores, a device could still be pretty good as a router.

Not enough CPU

Posted Nov 4, 2024 17:17 UTC (Mon) by shemminger (subscriber, #5739) [Link] (7 responses)

The problem is that preventing bufferbloat requires more CPU than most SOHO routers have.
A typical Armv8 Cortex A53 can't run CAKE at 1G bit. It tops out at about 700Mbit for me.

Not enough CPU

Posted Nov 5, 2024 2:18 UTC (Tue) by mtaht (guest, #11087) [Link] (4 responses)

I keep hoping to find a way to make cake's shaper multicore.

CAKE single-threaded?

Posted Nov 5, 2024 6:03 UTC (Tue) by DemiMarie (subscriber, #164188) [Link] (3 responses)

Why is multicore shaping hard? Single-threaded shaping is definitely going to be more and more of a bottleneck.

CAKE single-threaded?

Posted Nov 5, 2024 10:38 UTC (Tue) by Sesse (subscriber, #53779) [Link] (2 responses)

Fair queueing has, by definition, a lot of state. Anything involving large amounts of shared state is pretty hard to multithread efficiently.

CAKE single-threaded?

Posted Nov 5, 2024 15:43 UTC (Tue) by mtaht (guest, #11087) [Link] (1 responses)

I have been thinking about a shared timed token bucket, but really have got nowhere. Ideas over here: https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoi...

If you are willing to give up pure fq and instead just try to schedule per core the complexity goes down.

CAKE single-threaded?

Posted Jan 19, 2025 4:59 UTC (Sun) by Simon80 (subscriber, #50887) [Link]

Would pipelining help make multicore more feasible for Cake? Specifically, instead of load balancing packets across cores, each packet would go through the same pipeline in order, with each stage executed on a different core. I don't know enough to guess whether that approach is applicable here, but if so, it would make it possible to keep processing every item in a single thread, and still benefit from multiple cores.

Not enough CPU

Posted Nov 5, 2024 3:58 UTC (Tue) by jalla (guest, #101175) [Link] (1 responses)

It is a toy, unfortunately. pcengines had the same performance characteristics on the ancient jaguar platform, but with 3 m.2 slots. What a uniquely bizarre device in 2025. Mozilla made this mistake with boot2gecko only targetting beyond low end hardware.

If you're looking for something close to open, check-out odroid (which, is also ancient at this point on arm).

Not enough CPU

Posted Nov 6, 2024 8:01 UTC (Wed) by parametricpoly (subscriber, #143903) [Link]

Indeed. Banana Pi / Sinovoip people have a long history of making shit products. I think the earlier router routed all traffic without limitations while the router was booting. Not exactly secure. Also wtf is with providing images that don't work. This is something the Banana Pi makers have been doing all the time. While the community provides working open source images, they like to stick with binary BSP images that break the GPL.

“Offer for Source” is quite prominent on the box and also printed on PCB!

Posted Nov 4, 2024 18:06 UTC (Mon) by bkuhn (subscriber, #58642) [Link] (13 responses)

Jon wrote in article above:

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.

Build/Install instructions are in the source code (of course)!

Posted Nov 4, 2024 20:12 UTC (Mon) by ossguy (subscriber, #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:

A nice tutorial on how to build a custom image for this device would be welcome.

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 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.

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.

Prominent notices

Posted Nov 5, 2024 19:59 UTC (Tue) by comex (subscriber, #71521) [Link] (11 responses)

I notice that the tarballs don't have .git directories and so don't encode Git history. Given that, how are you complying with GPLv2 section 2a's requirement to "cause the modified files to carry prominent notices stating that you changed the files and the date of any change"?

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.)

GPLv2§2(a) does not say what you think it says

Posted Nov 5, 2024 21:17 UTC (Tue) by bkuhn (subscriber, #58642) [Link] (10 responses)

> I am … trolling

🙄 … 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.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 10:33 UTC (Wed) by paulj (subscriber, #341) [Link] (9 responses)

The text of the GPLv2 can stay unchanged, but the practical requirements of meeting it can easily change, given the GPLv2 refers to customary practice wrt software interchange.

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.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 12:34 UTC (Wed) by pizza (subscriber, #46) [Link] (5 responses)

> 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.

The tarball _is_ the "complete corresponding source code."

The git commit history is _not_.

End of story.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 12:37 UTC (Wed) by pizza (subscriber, #46) [Link]

Adding to this, the "git history" can _easily_ contain things that (a) the organization does not have the legal right to redistribute, and (b) has nothing to do with the GPLv2 software in question.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 13:14 UTC (Wed) by paulj (subscriber, #341) [Link] (3 responses)

The tarball is not, these days, the source code in the form preferred for making modifications. If you have:

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).

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 13:31 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> 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).

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?

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 13:43 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

If you have a reference to somewhere where the FSF defines source code as something different to the "preferred form of the work for modifications", I'd be interested to read that. Regardless, the term "source code" is explicitly defined in that way in the GPL text itself - if there's some pronouncement on some obscure web page somewhere, that probably doesn't matter.

Further, again, it's explicitly defined in a way that allows the meaning to be context (including temporal) specific.

GPLv2§2(a) does not say what you think it says

Posted Nov 6, 2024 16:04 UTC (Wed) by pizza (subscriber, #46) [Link]

I can comply with your interpretation by supplying at tarball that contains a git repo with a single commit -- The complete corresponding source code to the binary I'm distributing. I am under no obligation to supply the source code to binaries I did not distribute, nor am I under any obligation to distribute any/all prior versions of the source code. [1] [2]

...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)?
[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

Posted Nov 6, 2024 15:55 UTC (Wed) by ballombe (subscriber, #9523) [Link]

> The customary practices of the software industry have changed greatly since the GPL was written.

SCCS (1973) <https://en.wikipedia.org/wiki/Source_Code_Control_System>
RCS (1982) <https://en.wikipedia.org/wiki/Revision_Control_System>
CVS (1986) <https://en.wikipedia.org/wiki/Concurrent_Versions_System>
GPLv2 (1991)

So at the time the GPL v2 was drafted, version control system were already in use by professional developers,
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

Posted Nov 7, 2024 12:49 UTC (Thu) by bkuhn (subscriber, #58642) [Link]

> The text of the GPLv2 can stay unchanged, but the practical requirements of meeting it can easily change, given the GPLv2 refers to customary practice wrt software interchange.

GPLv2 refers to “customarily” only in GPLv2§3(a). Indeed …
…
> 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.

… 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.

GPLv2§2(a) does not say what you think it says

Posted Jan 19, 2025 9:55 UTC (Sun) by Wol (subscriber, #4433) [Link]

> 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.

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,
Wol

M.2 PCIe Possibilities?

Posted Nov 4, 2024 18:51 UTC (Mon) by sub2LWN (subscriber, #134200) [Link] (1 responses)

Aside from adding an SSD or two, I wonder which other devices people will add to these systems. Could new wifi modules be installed in those ports as the standards evolve? Or is there some limit to this based on the configuration of the board, power draw, etc? Maybe an M.2 GPS card could be used to add a high tier time server to the network? Aren't there some system-on-a-chip designs for this port, or FPGA boards at least?

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.

M.2 PCIe Possibilities?

Posted Nov 4, 2024 20:35 UTC (Mon) by rknight (subscriber, #26792) [Link]

Also wondering if the MikroBUS connector can make use of any LTE devices such as https://www.mikroe.com/4g-lte-na-click.

WiFi

Posted Nov 4, 2024 20:26 UTC (Mon) by cen (subscriber, #170575) [Link]

I would consider this for a WiFi hotspot but I need to see some benchmarks first.

Open Hardware?

Posted Nov 5, 2024 12:38 UTC (Tue) by dvrabel (subscriber, #9500) [Link] (3 responses)

The hardware itself does not seem to be open? Is it intended to be when it becomes generally available?

Open Hardware?

Posted Nov 5, 2024 14:48 UTC (Tue) by corbet (editor, #1) [Link] (2 responses)

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?

Posted Nov 5, 2024 19:45 UTC (Tue) by dvrabel (subscriber, #9500) [Link] (1 responses)

Open in the same sense as "Open Source", in that it permitted to freely create and distribute derivative works of the hardware design.

I don't see any licensing information for the provided schematics, the kicad project file is missing, and there are no PCB design files.

Open Hardware?

Posted Nov 6, 2024 7:46 UTC (Wed) by Wol (subscriber, #4433) [Link]

> I don't see any licensing information for the provided schematics, the kicad project file is missing, and there are no PCB design files.

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,
Wol

I'm wondering why?

Posted Nov 7, 2024 9:55 UTC (Thu) by NRArnot (subscriber, #3033) [Link] (3 responses)

What are the advantages of this device, over the flood of mini-PCs obtainable from China for the price of a router? They usually have 2 x 2.5Gbps Ethernet, those sold for routing (usually with PFsense preloaded) have four or even more. CPUs are anything from a J1900 to N300, usually 8Gb RAM, usually 128Gb NVME, and plenty of USB 2 and 3 ports. A power brick is normally included. I can't think of any reason they can't run OpenWRT.

Why am I wrong to think this may be too little too late?

I'm wondering why?

Posted Nov 7, 2024 12:15 UTC (Thu) by pizza (subscriber, #46) [Link] (2 responses)

> What are the advantages of this device, over the flood of mini-PCs obtainable from China for the price of a router?

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)

I'm wondering why?

Posted Nov 7, 2024 18:26 UTC (Thu) by rknight (subscriber, #26792) [Link] (1 responses)

>> What are the advantages of this device, over the flood of mini-PCs obtainable from China for the price of a router?
>Fully integrated and ready to go?

>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.

I'm wondering why?

Posted Nov 8, 2024 10:55 UTC (Fri) by paulj (subscriber, #341) [Link]

There are many routers based on the same MediaTek MT7981B SoC on aliexpress. Many of which ship with OpenWRT. Including the OpenWRT One box.

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.

Thank you

Posted Nov 8, 2024 16:49 UTC (Fri) by carlosrodfern (subscriber, #166486) [Link]

Thank you for reviewing OpenWRT One in such details. I was wondering about it. I have been an OpenWRT user for my wifi routers for a while, and I was interested in a device with OpenWRT out of the box.

Production version of OpenWrt One released

Posted Nov 29, 2024 21:05 UTC (Fri) by ossguy (subscriber, #82918) [Link]

As of today, you can now buy the production version of the OpenWrt One (from https://www.aliexpress.com/item/1005007795779282.html for example), which contains a full OpenWrt system, including LuCI. More details about it here:

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-...