New Threats to Asus Routers, few details.

[RMerlin]

It is complex enough now that only a few people could possibly understand everything inside - and it's probably close to the point where starting fresh is going to be less expensive than maintaining the existing software.

Luckily for Asus, a lot of their devs and managers have been there since the early days of Asuswrt (they forked it from Tomato in 2010 or 2011).

And that growing complexity is why I had to constantly narrow down the scope of what I am comfortable with modifying within that code. There's no way I can get even remotely close to having a broad enough understanding of a codebase for which Asus has a whole team of developers devoted to.

 

[RMerlin]

To put things in perspective: the oldest GPL archive I still have on my NAS is the 3.0.0.4.372_1393, from 2013 (that was when they added their first ARM platform with the RT-AC56U). That compressed archive is 400 MB.

Today, the average GPL archive is between 1 GB and 1.6 GB, depending on the model. And that`s for one single model.

I`ll let you imagine the size of their whole git repo where every SDK platform is included. I know what size it was a few years ago, and I'm pretty sure your best guesses would underestimate that size...

 

[sfx2000]

Luckily for Asus, a lot of their devs and managers have been there since the early days of Asuswrt (they forked it from Tomato in 2010 or 2011).

If you want to see how things have evolved - Belkin still sells routers, and they had a mediatek based WiFi6 (RT3200) device that is basically classic Linksys WRT with mediatek's SDK merged in...

Tarball is here - https://s3.belkin.com/support/assets/belkin/gpl/RT3200_v1.2.00.360516.tar.gz

When you look at their file/folder structure... you might find it somewhat familiar

FWIW - Mediatek, much like QC-Atheros' QSDK, their SDK is also based on OpenWRT with all their closed source drivers/toolchains/etc - it's not OpenWRT per se, but the frameworks are there so they can support all their different chipsets...

 

[RMerlin]

If you want to see how things have evolved - Belkin still sells routers, and they had a mediatek based WiFi6 (RT3200) device that is basically classic Linksys WRT with mediatek's SDK merged in...

Tarball is here - https://s3.belkin.com/support/assets/belkin/gpl/RT3200_v1.2.00.360516.tar.gz

When you look at their file/folder structure... you might find it somewhat familiar

FWIW - Mediatek, much like QC-Atheros' QSDK, their SDK is also based on OpenWRT with all their closed source drivers/toolchains/etc - it's not OpenWRT per se, but the frameworks are there so they can support all their different chipsets...

I know that Broadcom has some kind of OpenWRT support in their recent SDKs as well, based on some discussions I've had behind doors.

 

[sfx2000]

I know that Broadcom has some kind of OpenWRT support in their recent SDKs as well, based on some discussions I've had behind doors.

That's the second time I've heard that now - doesn't mean that OpenWRT is looking to support Broadcom - rather similar to QCA and Mediatek, it's better that buildroot to support multiple chipsets...

 

[RMerlin]

That's the second time I've heard that now - doesn't mean that OpenWRT is looking to support Broadcom - rather similar to QCA and Mediatek, it's better that buildroot to support multiple chipsets...

No, but it means hardware manufacturers can now get a Broadcom licence, get the OpenWRT source code, and build a commercial product out of it.

 

[Tech9]

It is complex enough now that only a few people could possibly understand everything inside

I would like to see simple to fix bugs fixed like copy/paste massages from older firmware versions not valid anymore, help tooltips with wrong copy/paste information, GUI elements. This is what all the users see. What's underneath - Windows 98 that has to be re-written completely, but no one wants to.

 

[sfx2000]

No, but it means hardware manufacturers can now get a Broadcom licence, get the OpenWRT source code, and build a commercial product out of it.

I suppose they could - but GPL gets in the way of things there - it's always the lawyers that spoil the fun I guess...

 

[sfx2000]

This is what all the users see. What's underneath - Windows 98 that has to be re-written completely, but no one wants to.

Many people like sausage - but really don't want to know what is inside

As I mentioned - the complexity under the AsusWRT skin is truly amazing, and in some ways, a tribute to those that maintain it...

What I thought might be a simple bug fix, and in OpenWRT it would be, after a week of digging around inside the code, with hints provided by folks that _know_ it, I can't do a clean/tested fix, as it would impact devices outside of the one I have at hand, along with the mentioned mobile app and AIMesh configs.

The bug I'm chasing, as mentioned, is in how WL_2 is configured - it's turboQAM support, and they're basically violating a bunch of rules - not Asus perhaps, but Broadcom... most clients are ok with this until someone makes a change - it's actually a sev medium bug perhaps, but one that affects non-windows clients because some of them, including intel, look at the actual frame structure - intel on linux was the first clue, but as I dug into it, ath10k/ath11k also saw the same issue, along with ESP32/ESP8266 chips that are common in IoT devices...

I would add that in 2.4GHz - this bug could actually be a cause of many of the mobile handset issues with devices bouncing on/off the WLAN - again, depends on how the UI is set, and how the driver underneath is configured.

There's always the group-mind approaches - disable this, enable that, beamforming, airtime fairness, etc - but that's dancing around the real bug with potential workarounds, not addressing the real issue at hand.

The fact that ath9k is so well documented and open helped sort the bug.

I've fixed it for AC-68U, but that same change might not work for other SDK versions and I can't test this due to lack of devices (clients and routers) completely - so a pull request is not pending.

I'll likely just document the bug, giving my discovery results, and move on.

 

[RMerlin]

suppose they could - but GPL gets in the way of things there

Not necessarily. Plenty of manufacturers have used OpenWRT with a closed source driver in the past. They only need to provide a buildable image by including prebuilt binary blobs, like all manufacturers already do.