About the Linux Kernel Version of the firmware of ASUS WiFi 7 router

[luckybeans]

Can anyone tell me the Linux kernel version of the Asus BE series router using the Broadcom WiFi7 chip? Use uname -a to check.

The Broadcom SDK used by Asus firmware is always not as good as it should be. I think this info can help a lot of people who want to buy it.

 

[RMerlin]

4.19.xxx (I forgot which exact revision).

 

[sfx2000]

The Broadcom SDK used by Asus firmware is always not as good as it should be. I think this info can help a lot of people who want to buy it.

How does this even matter?

The Broadcom SDK has to choose a kernel to base on - there they do much work to optimize things for the task at hand...

 

[RMerlin]

How does this even matter?

The Broadcom SDK has to choose a kernel to base on - there they do much work to optimize things for the task at hand...

The silly part is they picked 4.19 for their Wifi 7 platform. Wifi 7 devices based on that SDK started coming to market in 2023. And the end of support for kernel 4.19 is... December 2024.

That means by the time 90% of devices based on that SOC will come to market, the kernel will be only a few months away from being EOL.

5.10 or 5.15 would have made much more sense for a platform that is expected to see new products released for the next ~2 years.

 

[John Fitzgerald]

The silly part is they picked 4.19 for their Wifi 7 platform. Wifi 7 devices based on that SDK started coming to market in 2023. And the end of support for kernel 4.19 is... December 2024.

That means by the time 90% of devices based on that SOC will come to market, the kernel will be only a few months away from being EOL.

5.10 or 5.15 would have made much more sense for a platform that is expected to see new products released for the next ~2 years.

Just wow. That’s saying a lot. I don’t think I’ll be going to the ticket window to bet on that horse.

 

[sfx2000]

The silly part is they picked 4.19 for their Wifi 7 platform. Wifi 7 devices based on that SDK started coming to market in 2023. And the end of support for kernel 4.19 is... December 2024.

4.19 is a solid kernel, and in my experience with BSP's, it's a fork and backports for security issues are generally brought in...

Gaah - everyone wants the latest/greatest without understanding what's in the SDK kernel - it's not generic...

 

[RMerlin]

4.19 is a solid kernel, and in my experience with BSP's, it's a fork and backports for security issues are generally brought in...

If the kernel goes EOL, I'm pretty sure device manufacturers won't have the skill to backport future security fixes. As for Broadcom, I have my doubts about them doing so once past the EOL date. Something they could have avoided just by going with a more sensible LTS kernel at the time they created the BCM4916 SDK.

Gaah - everyone wants the latest/greatest without understanding what's in the SDK kernel - it's not generic...

Nobody is asking for kernel 6.x here. We're just asking for an LTS kernel that will get bugfixes and security updates for longer than just 6 months.

Broadcom doesn't seem to do anything there. There were a few security issues in the kernel in recent years that I ended up backporting fixes myself, as Broadcom never did.

I know very well what level of customization is present in Broadcom's kernel. I've had first hand experience with this for the past 10+ years. There isn't as much in their HND kernels as there used to be in their old SDK6/SDK7 kernels, which contained a significant amount of backports from 3.xx.

 

[RMerlin]

To compare, Qualcomm's Networking Pro 820 platform uses kernel 5.4, which will EOL in December 2025, which is at least a bit better.

 

[L&LD]

All the more reason to avoid Gen 1 (and even possibly Gen 2) WiFi 7 routers.

Thank you, RMerlin.

 

[RMerlin]

All the more reason to avoid Gen 1 (and even possibly Gen 2) WiFi 7 routers.

Thank you, RMerlin.

The Wifi 6 routers aren't going to get better support...

 

[kaanaslan]

Isn't this Kernel or the SDK version something that could be updated via Firmware?

 

[ColinTaylor]

Isn't this Kernel or the SDK version something that could be updated via Firmware?

No.

 

[RMerlin]

Isn't this Kernel or the SDK version something that could be updated via Firmware?

The SDK is what generates the firmware.

 

[L&LD]

The Wifi 6 routers aren't going to get better support...

Yes, but they're not priced into the stratosphere either.

 

[sfx2000]

If the kernel goes EOL, I'm pretty sure device manufacturers won't have the skill to backport future security fixes. As for Broadcom, I have my doubts about them doing so once past the EOL date. Something they could have avoided just by going with a more sensible LTS kernel at the time they created the BCM4916 SDK.

Well - one isn't going to be able to backport for every CVE - but High and Critical can usually be backported if not mitigated some other way...

While this thread is on the kernel, it's the other components that are also at risk - busybox and openssl are ones that get a lot of hits, and let's not mention dropbear, samba, netatalk and the like... it's those component that are the bigger risk, along with the proprietary code from the OEM's themselves..

Then we can do the path of the closed source drivers for network interfaces...

 

[sfx2000]

To compare, Qualcomm's Networking Pro 820 platform uses kernel 5.4, which will EOL in December 2025, which is at least a bit better.

Last time I looked at the QSDK - they're off the trunk, so their kernel is somewhat "private" in that once they commit to that kernel, they don't pull from upstream. They do commit upstream from time to time, and they will do CVE fixes for many CVE's on their own...

Once the OEM locks down their code for the device, typically they won't pull any updates from Qualcomm, so essentially they're a snapshot of a snapshot...

On a past project - we would do a CVE scan against the kernel and other upstream components in the BSP, and do the review for any possible impact, and remediate accordingly - normally addressing the Medium, High, and Critical items if they were not addressed already by Qualcomm...

The generic kernel, as we all know, is pretty large and complex, and has a lot of subsystems that are not built by default, and more importantly, in a Router application, we typically turn off in kconfig any unneeded options - mostly to reduce the size of the kernel, and reduce complexity where it is not needed - this is for maintaining the kernel over time, and to reduce the security surface.

So between internal efforts, along with the occasional maint update from the chipset vendors, it's not as big of a task as it sounds like - most quality vendors I know have at least a couple of dedicated kernel devs on the team...

 

[sfx2000]

To compare, Qualcomm's Networking Pro 820 platform uses kernel 5.4, which will EOL in December 2025, which is at least a bit better.

QSDK does provide "releases" from time to time, and of course they have their private "master" where everything is on the tip (which most folks wouldn't want to be - being on master is for development, and running on the tip is mainly for QA and integration)

Found this from Qualcomm over in the PRPL foundation document well - it's a good illustraton of how this works, and this is pretty much the same for any of the vendor SDK's (MediaTek for example, like Qualcomm, builds off OpenWRT)

 

[Logi]

The Wifi 6 routers aren't going to get better support...

If I understood correctly the previous comments, we are stuck with Kernel 4.19 even with the AX88U Pro who was released less than a year ago, they have to do something about it?

@RMerlin what do you think is going to happen then?

 

[RMerlin]

If I understood correctly the previous comments, we are stuck with Kernel 4.19 even with the AX88U Pro who was released less than a year ago, they have to do something about it?

@RMerlin what do you think is going to happen then?

Nothing is going to happen. The platform is based on a specific kernel version, and that version will never change.

 

[glens]

Not that it couldn't change, rather it's by and large a done deal for, say, Broadcom, who develops a working system and offers it "as is" to the customer who, making it easy on themself, also offers it "as is" to theirs.