[smashed]

It's not openwrt even though they pretend it is in their marketing. It's based on openwrt and might be "compatible" to some level with other openwrt packages.

When asked for full source code they seem transparent about it:

https://forum.gl-inet.com/t/source-code-for-gl-firmware-and-...

You can't reproduce their images and they don't share the improvements.

Of course not GPL compliant but not a concern in China I believe.

[aspenmayer]

You can check if your GL-iNet product supports native OpenWrt here:

https://www.gl-inet.com/support/firmware-versions/

You might find some sources here:

https://github.com/gl-inet

The issues regarding GPL compliance or lack thereof are worth noting, however. I made a point of asking for native OpenWrt firmware for the products I have from them, only to discover after the fact that due to closed source firmware blobs, it will likely never be available in that format, which was somewhat disappointing.

Given the fairly low/competitive price point of their hardware, I think it’s worth taking the time to make sure that the device suits your needs in that regard, if it’s important to you.

[nickysielicki]

The bigger deal is the lack of an open source BL2/BL31, but that’s me with my tin foil hat.

Sent from my iPhone

[aspenmayer]

Are you referring to open source BL2/BL31 for GL-iNet products, and/or for OpenWrt One? I’m not sure it’s possible with either, as haven’t looked into the One in detail yet, as I wasn’t aware it had launched until TFA was posted, though I was aware of it since January or so.

I’d like to run fully open source network stack if possible myself, though I’m not sure if that possible without moving the goalposts and virtualizing something or doing it in software, and even then I’d have to figure out some kind of boot attestation ideally, thought I'm not sure how that's going to pan out. Isn't Intel SGX/AMD SEV/ARM CCA required for that?

Some links I thought we interesting on that topic, as it's adjacent to the discussion:

> A comparison study of intel SGX and AMD memory encryption technology

https://dl.acm.org/doi/10.1145/3214292.3214301

> vSGX: Virtualizing SGX Enclaves on AMD SEV

https://ieeexplore.ieee.org/document/9833694

What do you suggest? How’s your hat fitting, by the way?

Here's the firmware for the OpenWrt One, if that helps you determine whether it does what you want:

https://firmware-selector.openwrt.org/?version=SNAPSHOT&targ...

If you find the answer to your/our questions, please let me/us know!

Sent from my iPhone in Lockdown Mode

[anonym29]

>It's not openwrt

This isn't entirely accurate. It absolutely is running a full OpenWRT instance. In addition to that, they have produced their own UI/shell, which is the default that you'll land on, but it's not difficult to get into LuCI.

That said, I'm not stating that it's only running OpenWRT, or that the OpenWRT instance it is running is unmodified, or trustworthy.

That said, I have struggled to get gigabit wireguard VPN throughput on other devices that support OpenWRT.

I love FOSS, I love self-hosting, I love DIY-friendly tinkerer-friendly, and I love high levels of user control, I just wish the ecosystem that prioritized these things had a stronger emphasis on high-end hardware that offers high performance.

[throwaway2037]

    > Of course not GPL compliant but not a concern in China I believe.

I don't believe this. There are multiple cases where GPL was enforced by Chinese courts.

Example: https://www.ifross.org/?q=node/1676

[jitl]

Posted case does not enforce GPL

[olalonde]

And they're headquartered in Hong Kong.

[1vuio0pswjnm7]

"The GL.iNet OEM firmware is a fork of OpenWrt and thankfully is compatible with official OpenWrt sysupgrade images, so returning to OEM is done simply by flashing their sysupgrade image without keeping settings and vice versa."

With GL.inet the buyer can install their own OpenWRT images. The OEM OpenWRT fork is a means of installing the buyer's choice of OpenWRT image.

For Cudy, another Chinese OEM, OpenWRT ToH refers to this as "Intermediate Firmware". See, e.g., https://openwrt.org/toh/cudy/tr1200

An OEM OpenWRT fork ("intermediate firmware") is (pre)installed, allowing a buyer overwrite it with an open source, GPL compliant OpenWRT image of their choice downloaded from openwrt.org or one compiled from source code downloaded from openwrt.org.

OpenWRT One is a Banana Pi board. Like GL.inet or Cudy, the Chinese OEM has their own system images.^1 Can a buyer reproduce them. 1. For example, https://docs.banana-pi.org/en/BPI-R4/BananaPi_BPI-R4#_system...

[microtonal]

It's not really an issue, since OpenWrt has full support for this device. IIRC the support in OpenWrt 23.05 is pretty good, I have been running 24.10 on a Flint 2 that we use as an AP and I've had zero issues.

I'd argue that even though by default the Flint 2 has a nicer interface for beginners, vanilla OpenWrt is much better. E.g. their old OpenWrt 21.02 build with the proprietary Mediatek SDK does not support baby jumbo frames, which are used by a bunch of providers that still use PPPoE (to get better performance).

[orra]

Yeah, you'd definitely want baby jumbo frames if you live in the UK. ISPs here almost universally use PPP.