Im covering 2 floors, the range of the router covers the whole house, pretty much full speed everywhere, my 2 PC’s are hardwired, everything else is just things like Alexa’s, lights, camera’s, phone and TVs, Sky stream box etc which im not too bothered about as long as they are working, 36 devices in total with everything connected.
hopefully some good updates coming soon: mac80211: add AQL support for broadcast/multicast packets · openwrt/openwrt@95e633e · GitHub
3 Likes
I noticed theres just published even a newer commit 
Are these fixes related to 2.4 and 5ghz? What are we facing?
I’m not entirely sure by 100% 
a time ago I checked out this commit also the one oly posted, but I didn’t saw a huge increase.
however currently they are making a huge jump in kernel changes (kernel 6.6 as experimental setting), and there were also some newer mediatek commits which may influenced, it works a little better but not equal or better than the mediatek sdk one not yet.
I guess it more proofs they are on something now
my 2.4ghz is becoming better than it was before though
I understand, is the latency still bad? on both networks? Could you do a test for us and post it here?
Good question i did a quick check on 2.4ghz (from 5ghz im unaware of issues.)
I got conflicting results:
Speedtest tells me a better ping.
Both tests where in the other room with a plaster wall (maybe 8 meter distance) and my phone pointing to the wireless AP.
I also tried my kitchen scenario, yesterday i was more optimistic until i figured out it failed, this is about 2 rooms and around 15 meter distance.
If i place my phone on the kitchen table pointing away from the router it disconnects from wifi and gets trouble, if i point it to the direction it connects.
This means the issue is still there 
ive tested it with dutch country setting.
Device im testing it with is a Poco X6 Pro.
That’s without this last patch they released, right? It seems that this huge latency that occurs in 2.4 has been reduced, but we can’t be sure without testing
1 Like
I added the latest commit to it
It could be influenced by irqbalance should i try without it?
and there really was no progress on the latency issue, at least the download improved a little
I think irqbalance or fixing the cores manually will only improve the situation and not make it worse, so there won’t be much there.
1 Like
Im glad you feel confident that it is not a hardware issue. I feel the same way as Goose280672 and that it is hardware. Enough time has gone by and they do not appear to be making good progress.
EDIT: that was in reply to Dondi
1 Like
Yup I agree, especially the 2.4ghz 100mb/s limitation not that it really bothers me as I only have IoT devices connected to the 2.4ghz, but it would be nice to get what I paid for and have the advertised speeds, 7 firmware releases in and its never improved as you say, they fix one thing and break another.
What I don’t understand (I am not a programmer) is why they are messing around with the old Mediatek driver on an old version of OpenWRT (21.02). Since they know that the Mediatek driver works much better than the OpenSource driver shouldn’t GL.Inet be putting pressure on MEDIATEK to redo the driver to run under OpenWRT 23.05 as it must have contracted with MEDIATEK. That’s the solution rather than messing around with the opensource driver which is clearly inferior (And let the OpenWRT people continue to mess with that to see if there’s anyway to improve that)…The closed source Mediatek driver seems to be the way to go and just have it recompiled (or whatever is necessary) to run under OpenWRT 23.05 which was what it was supposed to be able to do.
2 Likes
well the reason to why it is old, mediatek maintains the OpenWrt source as a private fork, and adds patented drivers to it (not open for open source).
They label this as a software developement kit or (SDK) for short, its a framework for vendors only, they don’t give lossless drivers.
GL-iNet backports and adds code on top of that as base. , if they really want to they may can backport changes and kernel hop but this is very hard work, and may not give the right expectation and result, too much work when its just waiting until the open source mt79 driver in OpenWrt 23.05 works better, even if the OpenWrt in mediatek sdk is EOL it doesn’t mean it is the worst, many oem routers use these sdks as base, some of them are qualcomm based and use OpenWrt 15.5.
MT79 is different than the patented wireless driver, and is more social engineered / based on what they (OpenWrt) think the mediatek drivers do, with this they can better maintain kernels etcetera because they have their own code, which is with the mediatek sdk very hard.
2 Likes
If I would be a hardware or SoC manufacturer, why wouldn’t I release an open source driver so that my product can be used with as many different systems as possible?
Its probably due to licensing, they add propetairy things into these drivers which they want to defend for their chip competitors.
theres also other reasons why many of these sdks are lower versions:
often their argument is for stability, they just want something what always works and on top of that they use their wireless drivers on it, big brands like xiaomi, and redmi and tp-link often also use QSDK or MTK SDK but in fact also happen to run on lower OpenWrt versions.
+ there are also hidden optimalisations or hacks which OpenWrt wants to add in a clean way, one of these things im following was this discussion.
3 Likes
xize11,
Thanks for the explanation…I will say one thing…Waiting for mt79 to work (better) in OpenWRT 23.05 may or may not ever come to fruition. The chipset may have an inherent design flaw that cannot be overcome with the driver…My guess is that MTK know what the issue is but they ain’t gonna say anything because that would be an admission that they were selling a faulty design. GL.inet just wants this to be over in what is supposed to be their premier product. So trying to sell customers on the "Hey we’re going to use the Closed Source Driver and you’re going to be on OpenWRT 21.02 instead (Which is EOL). When customers purchased the Flint 2 router it was advertised as OpenWRT 23.05 NOT 21.02. The solution to make things right is to take the closed source driver and to attempt to make it work correctly under OpenWRT 23.05. If that means taking your best programmer and saying don’t do anything else and just concentrate on getting the closed source driver working under 23.05 because that’s what it was advertised to have is the correct thing to do …OpenWRT 23.05…Not an EOL version 21.02. I understand what you say that the closed source driver may not work correctly under 23.05 but it’s definitely worth the attempt to correct this whole affair. Personally it doesn’t affect me as I don’t even use the wifi on the Flint2 but I could see how someone who relies heavily on the wifi would be very upset and telling them oh don’t worry you can run on the closed source driver with Open-WRT 21.02 (EOL) and then everything will be peachey is just an easy out for GL.inet.
7 Likes
Tbh i don’t think it is a hardware flaw perse , if so mediatek sdk (4.5.7+) would show the same issues, which it didn’t for me.
But it is a experimental flaw, to early for upstream OpenWrt adoption, and totally unexpectation it went that route.
The images on Mediatek SDK use mediatek propetairy drivers, these are only in their image cannot be added to upstream openwrt because the kernel is too new and introducing tons of other issues you will have no control off as developer, these drivers work better as expected from a typical vendor firmware, now the concentration only lays into fixing regressions which are easier to fix than a open source driver.
To overcome the current issues from MT79 and also big leaps from OpenWrt upstream repo, the MTK sdk is the stablest approach towards a upstream release from OpenWrt once MT79 works nicely.
-
also yes, i don’t disagree with you that it adverts OpenWrt 23.05, but yea i accepted it as is, if i was in their position i might made the same mistake, but atleast im happy firmware is not locked to a arch which maybe not get support in OpenWrt
, honestly the Flint 1 was much worse than this one in that aspect . -
also i feel i need to correct something in case i created a wrong assumption:
if a image uses old openwrt kernel it does not necessary mean it is full with vulnerabilities, gl-inet can choose to backport these patches, they have done this prior aswell on the flint 1😉, but that is on them.
2 Likes
Hello
I noticed a problem that I don’t know if it occurred in other beta versions before the release on 3/11.
I have two links, WAN1 and WAN2, whenever I leave them in balance mode I notice that Wireguard stops working. I return to failover mode and it operates normally again.
Has anyone else noticed this?
I use GL’s ddns to resolve my public IP, which is not fixed, and external access to Wireguard
Wireguard client?
When in load balance mode, the data can goes either connetion, causing your IP shift from one to another frequrenet. But it may not be a problem of vpn client. The vpn tunnel should be built and goes to one connection only.