Then you are trimming down from GL-INET's firmware, nothing related to vanilla OpenWrt.
The driver, and other system updates from GL-INET is not following what vanilla OpenWrt does, take an example of previous mt76 driver with Apple device performance issue, it was fixed in vanilla OpenWrt for quite a few months and then GL to come and pick up the fix to incoporate back to their firmware. No matter how you build the image from GL you won't be able to get that fix before they pull from official OpenWrt, this is the main difference.
Official OpenWrt requires the driver/firmware to be "upstream to mainline kernel", this is how things become "scalable", currently many supported devices already had kernel 6.6 LTS support, so the next upgrade to 24.x would be easy, but for those unsupported devices? No way, since they are ugly patched to specific kernel, or non-open source, you have to wait for vendor upgrade.
I'm okay moving on, but I do hold firm on my statements that GL-inet's vendor firmware is not simply a reskinned version of OpenWrt.
The B3000 is not supported by the official OpenWrt project. You must be running gl-inet's vendor firmware in order to operate the device. Therefore, there is no such thing as a vanilla version for the OP's router (at least currently). Someone would have to add support for the device per all the comments at the top of the thread.
It's not just packages; it's literally about the SoC which is not currently supported by official OpenWrt. This means that you cannot build an image without using GL-inet's customized code.
That's not to say that you couldn't use the gl-inet repo/sdk and omit packages you don't need... I don't know how their build system works, but if they allow that functionality, there's no reason one couldn't work that way. However, it is not the same as building the official OpenWrt code and running it on the device.
If the code comes from the official OpenWrt repos, yes, it is "vanilla" firmware. If the device requires critical code or even precompiled binary blobs from other sources, it is not vanilla. Obvious exceptions are the simple hardware definition files (dts) and the like. But if the chipsets aren't supported in the official code and thus requires another code base to be included in the build, that is no longer considered official.
The driver, and other system updates from GL-INET is not following what vanilla OpenWrt does, take an example of previous mt76 driver with Apple device performance issue, it was fixed in vanilla OpenWrt for quite a few months and then GL to come and pick up the fix to incoporate back to their firmware. No matter how you build the image from GL you won't be able to get that fix before they pull from official OpenWrt, this is the main difference
Do you not see irony of this statement.
Guys, i am not here for a pissing match. You are clearly not as familiar with building openwrt from scratch or how to reverse engineer a firmware. I have be doing this stuff since white russian. I am not out to argue, or have a circular discussion about what valina openwrt is. I unlike most in this thread offered a starting point to realizing the underlaying openwrt firmware as the op requested. all this other stuff is clearly a matter of mislead opinions.
I'm out ...good luck waiting on your vendor updates
Indeed, good luck waiting for updates for the gl-b3000âŚ
GL.Inet's vendor firmware is qsdk based, semi-proprietary kernel v5.4.213 (v5.4.281 would be current), proprietary wireless drivers, NSS 'fun', loosely based on a badly butchered up ancient OpenWrt 19.07.x fork. If you or the OP want that, fine take it up with GL.Inet's support fora then - but that metastasised chimaera has nothing to do with OpenWrt⢠and it behaves significantly different from genuine/ vanilla OpenWrt⢠(with very significant configuration differrences, no package compatibility, limited package coverage, etc. pp.).
Yeah, you are the best in the world building firmware, and you believe you are the only one in this forum knows reverse engineering, and/or firmware building.
I'm not gonna argue with you anymore, and I don't need to wait for vendor updates since my devices running on vanilla OpenWrt which receives more updates than vendor one.
I must have offended you in some way, I sincerely apologize, I assure you, that was not my intention.
And for the record ... i never stated that the gl-inet vedor firmware was the same as vanila openwrt firmware. I have been saying that they are very different the whole conversation. I didn't realize the magnitude of differences, i admit. but its all outisde of the point i was making ... ever piece of gl-inet hardware i own ...runs valina openwrt firmwares that I BUILT from original vanila openwrt firmware without issue what so ever. I do not own a GL-B3000, I know nothing about the chipset. I was simply pointing out a method to check the underlaying firmware, which to your point , seems is rather useless anyhow. Great you see i just learned something, something I would not have learned had i not got involed in this thread .. like so many other valid question asked on these forums that are either not answer at all ... or receive blunt almost aggressive answers from members that should perhaps ask more questions themselves. You all do as you do and Ill do me ... try to be as helpful as I can to who ever I can, when ever i can
âŚbut, wifi7 support itself still requires a lot of additional work to become functional (kernel side, in mt76, in hostapd, in netifd - and the proprietary firmware blobs).
Is there any openwrt supported wifi 6E routers and if there are is there any significant improvement from wifi 6? I think I'm just going to make my own router atp so I wanna know if it would be better to just get something with a wifi 6e chipset or just get a good mini pc and buy a separate AP with it
One question, are you saying that the b3000 will not run vanila openwrt ...definitely ? Its been a while since I did any hardware stuff. My last contribution was ...tp-link wa901nd v3 support, tho i did not make the pr, i did do most of the patch work. If you think the b3000 has a shot .... i'd be willing to take it on
It does not run OpenWrt now, the ipq5018 SOC it is based on has zero support in OpenWrt yet and mainline support for ipq50xx is incomplete and very partial. It technically would be supportable, if the device in question has at the very least 512 MB RAM (it does), if there were dedicated development in OpenWrt on this target, following the preceeding work for ipq807x (functional) and ipq60xx (not quite official yet) - it's similar to those, but not identical. If there were development for getting ipq50xx supported on OpenWrt by experienced developers/ contributors, you would look at a time frame of 12-24++ months worth of work (just look at how long it took for ipq807x and ipq60xx), so far the developer/ contributor count working ipq50xx is 0.00.
It's possible, it 'just' needs a heck of a lot of work and dedication (very comparable to the effort that now still goes into ipq60xx), for a lower-end variant of ipq807x/ipq60xx - all while ipq807x support is already there, ipq60xx somewhat 'in reach' (but pending of QCA fixing their ath11k firmware for it) - and ipq53xx or ipq955x/ ipq957x being the new cool kids in waiting.
Don't get me wrong, there's no reason not to support it (for devices with >=512 MB RAM), but 'someone' will have to put in the development work necessary. If those would step up, great - just that no one did so far.
May I have your attention, please?
May I have your attention, please?
Will the real Slim Shady please stand up?
I repeat, will the real Slim Shady please stand up?
We're gonna have a problem here
[âŚ]
i am willing to do the work, not just to prove a point, but i think it will be neat project for me. Plus i've been itching to test out my new hot air station anyway. I'll get one ordered and start my research. In the mean time, anyone with one of these units thats is comfortable pulling logs ... please post what you,ve got here in this thread for now. I will start an offical support thread once i get the unit and have a look at some logs. @slh ... i will have questions for you soon, i'm sure of it
Strong recommendation, it would be a subtarget of qualcommax(/ipq50xx), based on kernel v6.6 and OpenWrt's main branch - and like ipq807x/ ipq60xx it needs to be 'maintainable' (so a reasonable amount of patches and plans to get them mainline, to reduce them over time[0, 1]).
No one expects more than from ipq807x/ ipq60xx, but also not less.
--
[0] so just shoe-horning the qsdk into it is not going to fly
[1] what happens if this isn't a priority is something you'll see in the realtek (rtl838x/ rtl839x/ rtl93xx) target right now and many other more exotic ones before.
ok, i'll start by looking at whats been done with the pq807x/ ipq60xx and try to somewhat adhere to what been done there in my approach. thanks for the tip
If you're willing to do that it would be great. I can't speak for anyone but I do still believe there's got to be a few people that buy that router and would be looking for an official version of OpenWrt without the extra nonsense. I personally believe the more routers supported the better for the community.
I was previously interested in getting one so I might as well go ahead and I could assist you with any logs or any requests IF you are sure of trying it out.
I'm sure the op of this thread would be appreciative
Ngl I've been interested in the development of OpenWrt for other devices. I don't know C but I know a bit of python and the basics of java. I mainly do tech repair and am more hands on with hardware so this will definitely be a cool process to see. Sounds pretty interesting
