Beta 4.8.0 op24 issues

The one that is preinstalled in this firmware (0.107.56)

Hi,

I didn't reproduce the issue.


Have you "keep settings" in upgrade the firmware?

If so, please let me know what was the previous firmware version (open-source or closed-source)?

1 Like

I just saw someone posted a comment in a similar thread on performance issues on this build regarding the max speed for high bandwidth connections. I saw similar results and I am reposting the link to the other thread here Flint2 4.8.0op24 speedtest

1 Like

4.8.0 OP24 wifi performance issue for me. Client on Wi-Fi and Beryl AX in repeater or WAN mode, achieving speeds of 300-400 Mbps, whereas previously in my environment, I was able to reach 650-700 Mbps.

Edit: Was able to achieve 700+ over lan and 350-400 mbps over wifi repeater mode with phone connected to beryl ax wifi. Performance seems to be similar to 4.7.4 op24

1 Like

I second that Beryl AX with 4.8.0-op24 FW has Wi-Fi performance issue once "hardware acceleration" is ON, if I choose "software acceleration" and also turn on "packet steering", the performance will be better.

2 Likes

@alzhao Hey team, just wanted to touch base about the op24 release. We’re still in beta, and I haven’t heard anything about the RC release or the target date for the supported GM build. Could we please get an official update from your Product Manager? It feels like we’re always chasing our tails when a small issue pops up in the MTK release, and we have to wait another 3 months for op24. I’m not in the fan corner of the op24 or MTK, but honestly, I’m really worried about getting your supported hardware to work together. I was told by support to use the op24 over MTK since the MTK release had issues with other hardware previously sold in a bundle on Amazon with WDS.

2 Likes

What’s so complicate about having op24 daily snapshots like we have for non op24?
And again, what is the point of persisting on non op24, when it is clearly a security nightmare, not to mention op24 has been confirmed by many (and also GL staff..) to be better.
I may agree for ATX/AX 1800, for which the mainstream openwrt is not officially released, even thought, it run MUCH MUCH better than GL very old build…
Thank you for listening!

1 Like

I guess op24 is not their priority.

I have been using Vanilla OpenWrt without any issue.

Op24 is a favor. Why would a company continue to dev a firmware that is newer than the version they can run on their latest device?

While OpenWRT is an excellent project and I would love to deploy to my hardware, not all of my hardware is supported yet by OpenWRT. I’ve noticed OpenWRT doesn’t have the same frequency of updates that we see with other platforms like OpnSense. I understand OpnSense may not be the best comparison since it’s not designed for consumer-grade routers, but I do wish OpenWRT would publish a clearer roadmap and provide regular updates about when there are new releases with stricter release timing so you can better anticipate when new hardware is added to the mainline.

As a user of GL products and a security consultant for industrial customers, I’m concerned about the lag in support - if things are bad on one part of the house they are probably bad in the other and termites infest everything. It makes it challenging to confidently recommend their commercial cellular and IoT gateway products for example if the consumer products never close the loop on open betas and actually release. I don’t want my reputation tarnished by designing a solution with 50-100 gateways only to have the hardware plagued by some issue that never gets patched.

1 Like

Op24 was committed to for the lifecycle of the product. Gl is on the hook for this and can always refund customers who purchased for this reason.

:rofl::joy::rofl: head on over to China. I for one am grateful they continue to support a product with 2 firmware versions. Btw, have you seen the F3…EOL in this sector of the market, comment filled. Nobody used Opensense in the corporate market that’s a cost cutting measure for small to med businesses and an enthusiasts niche

1 Like

to me, I think cutting off MTK sdk to prepare towards a full release cycle of OP24 would make much more sense, I also don't read about the special reason why mtk sdk outperforms, and I'm not talking about the gl sdk going out of beta.

Many of the issues I read on the forum, (not all), seem to be regressions either by porting logic from gl sdk to mtk sdk or from mtk sdk to op24, I personally think that is very unmaintainable.

and besides that, there are also other issues going on I'm not happy with... it's waiting until more packages segfaults or even core ones because they kept being moved between those major versions.

They really going to make a dependency disaster imo.

Just for the sake of these 2 issues alone, I deff would vote for one single firmware being concentrated to, the mtk sdk was put in live for the many issues OpenWrt had with the early adoption, I can say now that it is alot more matured, I don't have much of a issue running it (I run from master).

but as master snapshots already suggest, I won't recommend them as GL-iNet release, sometimes something big breaking can be introduced and needs some time to roll some of that back, like the sudden breakage of exotic wireless configuration due to the ucode changes as preparation for wifi7 MLO support in OpenWrt.

5 Likes

I don’t disagree but I don’t see GL moving to op24 on the F2 while the F3 can’t currently run past 23 due to closed drivers from QC. The MTK chipset has always had good open source support not sure why GL moved away on the F3. When OpenWrt made this chipset THEIR standard it changed to hardware game the F2 became one of the best supported platforms full open source.

4 Likes

I ended up moving everything to builds off of OpenWRT.org now - I had to build one custom firmware using their chipset selector for 3 devices that were too bleeding edge and not supported outside of the snapshot releases, but everything seems to be working for my hardware and it is better/more predictable than endless beta builds.

I really wish GL built a custom GUI manager on top of baseline open-source OpenWRT mainline, but they seem to want more control, and the chipset vendors don’t seem to automatically release their software for the chipsets in the public openwrt repository (they should). I doubt GL.inet has the leverage against different Wi-Fi chipset vendors to push for this - but honestly, how they manage and support all of these models now is unsustainable. Although there is a claim that they update for security issues exist for the out-of-support OpenWRT builds, what GL.inet does now is less than opaque and has me worried.

I ended up separating out a lot of my network services now just to avoid catastrophe from putting all my eggs in one basket. Wireguard and a PiHole server running in separate containers, a frontline IPS firewall with the GL.inet hardware running as primary AP, and 4 GL.inet AP extenders throughout my network, and I finally have the speed and performance I have been looking for. I wish I had taken the time earlier to do this, but I had to educate myself a bit more on OpenWRT first before I undertook this project since some hardware is not officially supported yet.

2 Likes

On my main router, I moved to vanilla OpenWrt as well.

They should focus on making a GUI-Only. A kind of “Friendly LuCi" exclusive for their devices (if they don't like to allow it to be used on others hardwares), instead of making a messy on the OpenWrt, creating bugs where there is no bug on vanilla OpenWrt.

7 Likes

I hope that they would at least make OP24 branch as their main firmware moving on. Clearly, lots of users favors OP24 more

4 Likes