Beryl 7 highly outdated openwrt

Hi

Regarding the use of OpenWRT 21.02:
As others have mentioned, firmware provided by SoC manufacturers (such as QSDK/MTK SDK) generally offers better stability, particularly for Wi-Fi performance. For this reason, we often adopt these SDK-based firmware versions when launching new products, even if the underlying OpenWRT version is not the latest.
As open-source drivers mature over time, we may release additional firmware versions based on upstream OpenWRT, similar to what we have done for the MT3000 and MT6000.

Regarding security issues and vulnerabilities:
If you or others identify any security issues or vulnerabilities in our stock firmware, please report them to us or email [email protected] (especially for unpublished issues). We take such reports seriously and will do our best to address them or provide appropriate solutions.

Regarding the Tailscale vulnerability warning:

  1. This vulnerability primarily affects users who have enabled the Tailnet Lock feature, so the impact is limited in scope. For reference, please see the official Tailscale security bulletin.
  2. Users who require an immediate workaround may update Tailscale manually using the community-maintained script by Admon.
  3. We will escalate this internally to assess the feasibility of providing an official Tailscale update in future firmware releases.
4 Likes

I installed (ran) the script that @admon made and it updated tailscale and that warning to update was gone. It’s nice to that these devices are well looked after, so thanks guys.

People need to stop chasing version numbers.

Let me shiver as I blindly post AI data but compare popular Linux distro kernel versions for example:

Ubuntu:
    24.04 LTS (Noble Numbat): Kernel 6.8 (upgraded from 6.6).
    22.04 LTS (Jammy Jellyfish): Kernel 5.15 (LTS).
    25.04 (Plucky Puffin): Kernel 6.14 (target).
Fedora:
    Fedora 43: Kernel 6.17 (latest).
    Fedora 40: Kernel 6.8.
Red Hat Enterprise Linux (RHEL):
    RHEL 9: Kernel 5.14.
    RHEL 10 (Preview): Kernel 6.12.
Debian:
    Debian 12 (Bookworm): Kernel 6.1.27.
    Debian 11 (Bullseye): Kernel 5.10.

Many times the “upstream” distro is either older or newer kernel or packages.

Just because your upstream has a newer version number doesn't mean you must chase the latest version.

And this is just some of the bigger Linux distros there is endless more variations littered through out the Linux landscape.

Are all these Linux distros incompetent and unusable if they are not running the latest kernel? Is the distro required to directly track every kernel or package that is somewhere upstream of it?

Stability and even security often comes from hand picking what versions work best together. And back porting specific fixes that impact your use of packages etc.

Turnkey hardware devices with specific needs for power, heat, and price like routers add even more complexity to this picture.

If you want to just run vanilla openwrt on a router, go buy a banana board. Good luck with getting good quality wifi. Setting up and maintaining the router security is entirely in your hands and openwrt volunteers/hobbyists.

I personally trust that a company like gl-inet create quality, well supported, well maintained devices that are suitable for their task.

There is nothing wrong with these gl-inet products. They are well supported and maintained by quality maintainers which includes companies like gl-inet, Broadcom, MediaTek etc.

With most above I agree but:

This is your opinion, and is irrelevant.

GL-iNet advertises with OpenWrt, so atleast the expectation is a form of OpenWrt, being sent to the wild of just going to a banana pi is not something what makes sense, and bpi is also not the kind of platform any enthousiast is having fun with, I got a BPI-R4 but never touched it because I had to flash the firmware more times through 2 modes to get it on the emmc, which I personally find ridiculous.

Yes, you are not wrong in a extend, but I stopped when you picked broadcom, this chip is the worst open source friendly for OpenWrt you can pick, maybe if in luck with DD-Wrt but Broadcom has a history of licenses and not wanting to release blobs at all to OpenWrt.

And besides Qualcomm is really slow in updating, Mediatek is still the better one, but GL-iNet does also backport things.

What I have a issue with is that GL-iNet have different toolchains and then put packages crosschained to other platforms, and this is a very risky thing because compilers in those toolchains use bytecode, and different versions can break things.

It is a very bad practice, which threatens the stability and potentially hides more breakage deeper in the kernel.

If they have limited resources such as space, I want them rather to concentrate to OP24 fully, as I stated again it's more damage control rather than taking the time to understand newer OpenWrt releases and the impacts it can have, I rather have them taking the time longer instead of handling with this problem, I mean porting the newer upstream sdk to OP24 will also cause extra afford, imo they do double or even tripple the extra afford wasting resources.

1 Like

Gl-iNet simply makes choices.

Using manufacturer SDK as base means the hardware of the device offers the best performance and the latest technology features. But at the same time, this may force you to use an old kernel, because that SDK is made using that.

Using 'stock OpenWRT' gives best OpenWRT experience. The open-source drivers may not exist yet for chips used. Or they may not be stable enough, causing devices to more frequently disconnect. Open source drivers or stock OpenWRT may not have all features. As example of that: Does OpenWRT/Luci already have Wifi7-MLO?

At the same time, stock OpenWRT is pretty difficult for many users to use. Especially if you want all kinds of more advanced features like doing WISP, multi-wan, all kinds of VPN... Many users needs those features way more dumbed down for these users to be able to use it that. So GL-iNet adds their own panel to make it much more user friendly.

So.... Often you cannot have all 3 :wink:

To be honest, this discussion has been HAD a million times. It is pointless to have, because this will not really change unless the qualcomms and mediatek would just make their latest stuff go in upstream OpenWRT straight away... Oh but copyright and NDAs and all such shit would be in the way.

3 Likes

OT: This sent me down a little rabbit hole trying to figure out what you were talking about. USB 3 standard is 4.5w, max (non PD), so a HDD is never, and an SSD is rarely, going to work. It's really for tethering or SD.

1 Like

Hopefully, GL.iNet products will not face a possible ban like TP-Link in the US. I love this attitude of taking security seriously!

Red Hat and Debian are also known for being really slow in updating kernel and packages. And I don't believe Red Hat or Debian are seen as horrible companies because of it. Instead they are the reliable/premium solution.

Many companies are not chasing the latest version numbers and instead put priority on stability and security.

Gl-inet and their upstreams are maintaining their code base. Just because openwrt changed version doesn't require Broadcom to change version in any particular time frame.

Gl-inet advertise their products is based on openwrt and it is.

They don't require to be on the latest openwrt to claim the OS is based on openwrt. If you want a gl-inet product with a specific openwrt version you would need to research and purchase a product once that information is available. Same with if you have specific demands for wifi features or switch port features etc.

Loads of the specifics about products is unknown before release. How is the specific openwrt version even the most important unknown? Before release it is often difficult to know the wifi features, os features, switch features, chipset used etc.

It is just more unreasonable demanding by the user for the extremely low cost product to meet their exact desires. I am surprised they haven't stated the product shouldn't exist because it lacks sfp.

What next, that the CPU isn't capable of running ai models locally which means the product is clearly so outdated and not fit for use?!

Mediatek have only two Openwrt branches available:

21.02 in use branch with 5.4 kernel

24.10 in use branch with 6.6 kernel

Both are regularly patched by Mediatek.

Using openwrt 21.02 IS a bit of strange. If you check the mediatek SDK documentation, the latest version for MT7987 is 24.10. Meanwhile, they have a 25.12 version available if you clone the repo, but they did not mention it in the doc, so it might not be stable.

2 Likes

Tethering, yes. But it cannot power a ZTE F50 usb cellular modem. And given that the Flint2, Beryl7, Slate7 and SlateAX (and some Cudy options), as well as any powerbank, PSU or PC usb port had no trouble at all powering the F50 and keeping it powered, that points to the Beryl AX having the issue. Same reported by others using the F50 (and more reports regarding external drives which may or may not be related) so also not a hardware defect in only my unit.

Also, curiously, the Chinese marketing for the Beryl 7 includes the fact that the USB port can deliver 5v2A and has a connection to a device which looks identical to the F50, just without any obvious branding.

Thankyou for the response.

Good to know there is a valid resolution for the Tailscale issue.