LWN: Comments on "Making the OpenWrt One"

Port configuration is ambiguous..

farnz — Tue, 13 May 2025 11:21:24 +0000

Our ISP was fairly typical - it was paying for 2x10G bearers to us, to provide a symmetric 500 Mbit/s service on top of those bearers.

The reason it paid for 10G bearers is that change of bearer is a slow process, since it involves taking down a bearer (or running fresh fibre) then replacing kit on both ends, whereas getting faster service is just a software change - and they wanted to be able to upgrade us on-demand to a more expensive 1 Gbit/s or 2 Gbit/s without delay.

This is not an atypical configuration for SME dedicated internet access (as opposed to "business" service on consumer products); fast bearer, slow service on top. You don't need more than 2.5 Gbit/s of internal network when you've got under 2.5 Gbit/s of external network, supplied on 2x 10G ports.

Port configuration is ambiguous..

pizza — Tue, 13 May 2025 11:07:25 +0000

> If that's why you want 2x10G, then this sort of box is useful; if you need high throughput, it's not so useful.

You make a valid point, but I do feel compelled to point out that having redundant 10Gb ISP uplinks but only 2.5Gb of internal network bandwidth seems backwards.

Port configuration is ambiguous..

farnz — Tue, 13 May 2025 10:57:02 +0000

We wouldn't have needed to do any of that - the reason for redundancy was not because we wanted it, but because our ISP insisted on it as part of the service (since the service came with a 6 hour SLA, after which they'd be paying out).

If the claims about diverse pathing turned out to be false, that would have been our ISP's problem - they'd have been paying out on a 6 hour SLA while chasing their suppliers to fix it ASAP.

And we'd agreed an SLA payout that was large enough that the business was better off with the Internet link down than with it up; we weren't foolish enough to believe that a "business" service meant it'd be prioritised for repair, but did believe that if we were getting more in SLA payouts than it was costing us to get alternatives (like LTE sticks for everyone), we'd be OK.

Port configuration is ambiguous..

paulj — Tue, 13 May 2025 10:45:42 +0000

> if we'd wanted 20G service, we'd have had to have 3 links, two primary and one failover to cover "backhoe fade" between us and our ISP.

You also need to obtain survey maps of where they have physically have placed their fibre, and /verify/ any claims they make about path independence of the fibres. Potentially down to hiring independent surveyors to verify such claims.

A certain large tech company lost connectivity for DC for a while once, discovering in the process their fibre suppliers had lied^Wwere mistaken in their claims about physical independence, when a JCB somewhere took out in 1 go a number of bundles of fibres that were not meant to be anywhere near each other. They significantly increased the level of verification of future supplier's claims after that.

Port configuration is ambiguous..

farnz — Tue, 13 May 2025 10:38:15 +0000

Note that, depending on use case, that box can be perfectly usable. For example, I have two interfaces between my home server and my switch, not because I need throughout increases (1G is plenty at the moment), but so that I have a redundant link, and when the wires break, I get a message from network monitoring telling me that I've lost redundancy, rather than losing service.

Similarly, at a previous job, we had 2x10G links to our ISP, consisting of a primary and a failover link; if we'd wanted 20G service, we'd have had to have 3 links, two primary and one failover to cover "backhoe fade" between us and our ISP.

If that's why you want 2x10G, then this sort of box is useful; if you need high throughput, it's not so useful.

Port configuration is ambiguous..

pizza — Tue, 13 May 2025 01:54:36 +0000

> What I wanted to say is that cheap x86 boxes are not *that* better than Arm boxes. You just exchange the drivers issues for other kinds of issues. So if you have an aversion to Arm SBCs and your plan for dealing with this involves buying a cheap no-name x86 thing instead, there is a chance that you might be disappointed.

I disagree; all of the problem those "cheap x86" systems have (eg underspec'd buses for the peripherals and nonexistant vendor support), "cheap ARM SBCs" also have in spades. The primary advantage for those Arm SBCs is their lower power consumption, but that's balanced by the huge disadvantage of being one-off special snowflakes that rarely move beyond "only works with the vendor's never-updated original pre-installed image".

Still, if those SBCs give "good enough" performance/features/etc that can be an overall win, though one has to consider how long it would take to come out ahead from the power savings.

Port configuration is ambiguous..

intelfx — Mon, 12 May 2025 21:03:38 +0000

> Generally I'd agree with you but when your headliner feature is so badly kneecapped... it rather defeats the purpose.

What I wanted to say is that cheap x86 boxes are not *that* better than Arm boxes. You just exchange the drivers issues for other kinds of issues. So if you have an aversion to Arm SBCs and your plan for dealing with this involves buying a cheap no-name x86 thing instead, there is a chance that you might be disappointed.

Port configuration is ambiguous..

pizza — Mon, 12 May 2025 13:51:27 +0000

> Do any of the designs have a PCIe switch chip involved?

Not that I could tell -- And using one would be likely be more expensive (if even possible to fit in that tiny form factor) than just using a PCIe3.x-capable 10GbE controller to begin with.

(That is probably why their devices with more ports use more capable SoCs -- on the lower end, they sport the Pentium 8505 which sports 20 PCIe 4.0 lanes...)

Port configuration is ambiguous..

pizza — Mon, 12 May 2025 13:35:50 +0000

> So... another instance of "you get what you pay for"? ;-)

Generally I'd agree with you but when your headliner feature is so badly kneecapped... it rather defeats the purpose.

FWIW the rest of the system appears to be more than adequate. Variations of this thing exist with more 2.5GbE ports instead of the 10GbE SFPs, which is fine. Other variations exist with even more ports, but they're built on much more capable SoCs with at least *20* PCIe lanes to play with. But none of those seem to be optionable with with 10GbE.

...FWIW, the i82599ES is used instead of something more capable because it's really, really cheap these days -- first released 16 years ago, and as it turns out, was formally EOL'd (order books closed and support formally ended) just seven days ago.

Port configuration is ambiguous..

farnz — Mon, 12 May 2025 09:38:24 +0000

Do any of the designs have a PCIe switch chip involved? The situation you're describing (PCIe 3.0 lanes on the host, PCIe 2.0 lanes on the device) is what switch chips excel at, since you can have 8 lanes of PCIe 3.0 to the host becoming 32 lanes of PCIe 3.0 facing the devices, with the switch chip operating on a per-TLP basis (so 8 lanes of PCIe 2.0 to the device consumes 4 lanes of PCIe 3.0 on the host side).

You'd be looking for something like the Microchip Switchtec family devices, or the PLX (now Broadcom) PEX family of devices; a cheap design would put the 10G controller, WiFi card slot and WAN card slot behind the switch, so that you can feed 4 PCIe 3.0 lanes to the switch, and have 16 PCIe lanes out (4x PCIe 3.0 for the WAN card slot and WiFi slot, 8x PCIe 2.0 for the 10G controller), and have WiFi card, WAN card and 10G ports compete for the 4 PCIe 3.0 lanes worth of throughput. If you're going overkill, you'd use a switch with more lanes, and have 8 lanes from the host to the switch, with more ports on the other side of the switch.

Port configuration is ambiguous..

intelfx — Mon, 12 May 2025 01:39:25 +0000

> > https://www.amazon.com/Healuck-Firewall-Appliance-OPNsens...
> I wanted to post a followup <...> That's... quite disappointing.

So... another instance of "you get what you pay for"? ;-)

Port configuration is ambiguous..

pizza — Mon, 12 May 2025 00:49:18 +0000

> As I'm not going to be able to wait until the end of the year for OpenWRT to build this new board (assuming it has the dual SFPs that I need), this is what I'll probably end up going with:

> https://www.amazon.com/Healuck-Firewall-Appliance-OPNsens...

I wanted to post a followup. The SoCs these CWWK designs are built on (N100/N150, or N305/N355 on the high end) only have a total of 9 PCIe 3.0 lanes. These lanes are split between a pair of i226 2.5GbE controllers, a slot for nvme storage, a slot for a wifi card, and one or two additional peripherals (second nvme slot, WAN card slot, and/or a third 2.5GbE controller) That means anywhere from 5 to 7 of the possible 9 PCIe lanes are already spoken for, leaving at most 4 (but more likely 2) for the 10GbE ports.

These designs all seem to use an i82559ES dual-port 10GbE controller, which is a PCIe 2.0 device whose documentation states an x8 link is necessary if you are seeking to run both ports at full speed. This means at _best_ (in a x4 setup and 0% overhead) this design provides only 80% of the raw bandwidth necessary for full utilization of both ports, and in an x2 configuration, it won't even be able to run a single interface at full duplex (or both at half duplex).

That's... quite disappointing.

OpenWRT One is not FSF RYF compliant

pizza — Thu, 03 Apr 2025 12:57:21 +0000

> For this strategy to be viable, OpenWRT One will need to remain 1) in production and 2) relevant enough for the time it will take to reverse engineer the blobs to the point they reach a sufficient level of functionality.

As someone who has written low-level radio firmware [1] and done a lot of hardware-level reverse engineering, the odds of this ever happening are vanishingly small.

(For the record, I *strongly* agree with the SFC's attitude towards firmware, and consider the FSF's "RYF" approach to be objectively and morally *wrong*)

[1] 802.11g-era Wifi, Bluetooth, and some custom stuff

OpenWRT One is not FSF RYF compliant

farnz — Thu, 03 Apr 2025 12:51:26 +0000

On the other hand, it's trivial to make the PC Engines APUs FSF RYF compliant - just add read-only media, and put the blobs on that media, then rearrange things so that the firmware can only be loaded from that read-only media (which could be as trivial as a rewritable flash chip with a track cut so that you can't assert write-enable).

At least in the case of the OpenWRT One, it's possible to free it; if I made the changes needed to comply with the FSF's RYF program, it is never possible to replace those blobs, ever - you are tied to non-free firmware forever.

OpenWRT One is not FSF RYF compliant

gioele — Thu, 03 Apr 2025 12:23:46 +0000

> I do find a great irony in the fact that the OpenWRT One has chosen to maximize the chances of being fully "Free Software" in the long run by doing something that's directly in opposition to the FSF's RYF program. The SFC is clearly encouraging people to reverse-engineer the blobs, and produce something that's fully Free, rather than shoving the blobs in read-only memory and meeting the FSF's RYF criteria with something that will never be fully Free.

For this strategy to be viable, OpenWRT One will need to remain 1) in production and 2) relevant enough for the time it will take to reverse engineer the blobs to the point they reach a sufficient level of functionality.

I wish OpenWRT and SFC success in their endeavor, but a counterexample could be PC Engines's APU units that have been widely deployed for two decades and underwent practically no hardware changes, yet most of their NICs and WiFi cards (all except one?) do not have free firmwares.

OpenWRT One is not FSF RYF compliant

farnz — Thu, 03 Apr 2025 11:29:16 +0000

I do find a great irony in the fact that the OpenWRT One has chosen to maximize the chances of being fully "Free Software" in the long run by doing something that's directly in opposition to the FSF's RYF program. The SFC is clearly encouraging people to reverse-engineer the blobs, and produce something that's fully Free, rather than shoving the blobs in read-only memory and meeting the FSF's RYF criteria with something that will never be fully Free.

In the long run, I suspect that the SFC's approach will be far more effective than RYF; it's making it possible to fully Free this device in the long run, knowing that it'll not get Freed if in the short run, it's useless, or if Freeing it requires you to replace read-only memories for each test.

Port configuration is ambiguous..

Cyberax — Mon, 31 Mar 2025 16:51:00 +0000

It's not uncommon.

I have a 2Gb uplink to my ISP (that needs an SFP+ module), and I also want to make my NAS available via a 10G connection to multiple clients.

Port configuration is ambiguous..

pizza — Mon, 31 Mar 2025 12:22:33 +0000

> Out of curiosity, why do you need 2× 10Gbps links? Is it for some kind of failover, or do you actually require 20 Gbps of throughput on whatever side of the router (or is it two independent segments, each of which demands 10 Gbps)?

The latter. I have my network partitioned into two major segments (four if you count the redundant/failover ISPs) and I want to be able to route between them at full wire speed. If I trunked the primary VLANs together over a single 10Gbps link into the router, it would effectively halve the maximum bandwidth available between them.

(Runs between buildings are trunked, and if 10Gbps becomes a bottleneck I can light up the redundant fiber pairs. I can't currently justify the expense of >=25Gbps capable switches.)

Port configuration is ambiguous..

Wol — Mon, 31 Mar 2025 09:01:30 +0000

This is where it sounds like a "Pi with hats"-style design would be a good idea. Of course that jacks up the cost a bit, but if you only bought the hats you wanted that could keep it down ...

Cheers,
Wol

OpenWrt Two

intelfx — Mon, 31 Mar 2025 07:08:19 +0000

> [OpenWrt Two] would be a different kind of device, with two 10Gbps ports, several 2.5Gbps ports, and Wi-Fi 7. That will likely be available in late 2025; the OpenWrt One will still be available once that starts shipping. The SFC is exploring other device classes where it might be sensible for it to make its own hardware.

As indicated in the vote and alluded to in other comments, this thing is going to run on an MT7988, which amounts to 4×1.8GHz Arm Cortex-A73.

So, I guess, the money question is: will it run Cake at 1 Gbps? :-)

Port configuration is ambiguous..

intelfx — Mon, 31 Mar 2025 07:03:19 +0000

> Personally I'd much prefer an additional 10Gb SFP slot instead of that 5GbE port, as it(along with one copper port) would allow me to finally replace the 12-year-old 1U server that has been my home router for the past few years.

Out of curiosity, why do you need 2× 10Gbps links? Is it for some kind of failover, or do you actually require 20 Gbps of throughput on whatever side of the router (or is it two independent segments, each of which demands 10 Gbps)?

long term support

champtar — Sat, 29 Mar 2025 19:48:17 +0000

Having long term support is really important.
I ran OpenWrt on a Ubnt rspro from 2011 to 2023, in the end I had to replace it because it was a bit underpowered, and it would have been impossible to source a replacement in case of failure.

Port configuration is ambiguous..

Mook — Sat, 29 Mar 2025 18:27:00 +0000

The Two is (according to the initial proposal under vote linked by the article) planned to be manufactured by GL.iNet, so it's probably not quite the same as BPI-R4. It actually doesn't look like any of GL.iNet's existing devices, since none of the announced BE devices have SFP ports.

Port configuration is ambiguous..

pizza — Sat, 29 Mar 2025 01:02:53 +0000

> You can definitely get the BPI-R4 with 2x 10Gb SFP.

Thanks, but I've long since learned to avoid trusting anything important to Arm-based SBCs that won't function properly with a mainline kernel and/or boot with off-the-shelf distros. (A special snowflake vendor provided "preinstalled SD card image" doesn't count. Oh, and this includes most Raspberry Pis.)

As I'm not going to be able to wait until the end of the year for OpenWRT to build this new board (assuming it has the dual SFPs that I need), this is what I'll probably end up going with:

https://www.amazon.com/Healuck-Firewall-Appliance-OPNsens...

Port configuration is ambiguous..

zorg24 — Fri, 28 Mar 2025 19:18:57 +0000

My understanding is that OpenWrt One is based on BPI-R3 (with some changes to the board) and the two will be based on the BPI-R4, both are using MediaTek Filogic SoCs from the family\generation. You can definitely get the BPI-R4 with 2x 10Gb SFP.

Port configuration is ambiguous..

pizza — Fri, 28 Mar 2025 17:20:17 +0000

> [ OpenWrt Two] would be a different kind of device, with two 10Gbps ports, several 2.5Gbps ports,

Is there a definitive source for this? Because the text in the proposal (and all other reporting) says it is expected to be 1x 10Gb SFP, 1x 5GbE, 4x 2.5GbE (switch), and 1-2x 1GbE. (It's not clear if the 2.5Gb and 1Gb ports are on the same switch or are different logical interfaces)

Personally I'd much prefer an additional 10Gb SFP slot instead of that 5GbE port, as it(along with one copper port) would allow me to finally replace the 12-year-old 1U server that has been my home router for the past few years.

(I don't even care about having wifi! But it needs to ahve at least two 10Gb (or faster) SFP slots and 1-2x additional copper ports. )

Support

cen — Fri, 28 Mar 2025 16:54:11 +0000

I am quite satisfied with my OpenWRT One so far. I will probably replace any old network gear that fails or stops performing well with One, Two or whatever the future brings. Sure, you can flash a consumer router but that still means your money goes to that manufacturer, might as well just go straight with upstream now.

Overall this seems like a successful initiative so kudos to everyone involved.