Asus use different code for production and public GPL tarballs

[Banxian]

Recently I built a custom firmware for my RT-BE82U, because it lacks some DDNS suppliers (www.3322.org). After the firmware was built, I compared my rootfs (102_38152) to the Asus-released one.

I used fdtextract to save the `nand_squashfs` image to disk and found some interesting differences.

The official image_version file shows `5044p3GW0841920(BSPv1W13)`, and mine is `5044p3GW0730127(BSPv1W13)`, a bit older.
The official /usr/bin has extra files: `ceventc`, `ceventd`, `FcStats.sh`, `hw_accel_dump.sh`, `phy_scripts.sh`.
In my rootfs, `ceventc` and `ceventd` are under /usr/sbin. The official /usr/sbin has an extra `wifi_dsps.sh` file, which is short for WiFi Deep Sleep Power Save.

I wrote to Asus via their web mail form to ask for the newest GPL source for 39099, because emails to [email protected] are being rejected by the mail server. They said they will reply within a week.

 

[bennor]

@Banxian, are you using or mentioning Asus-Merlin firmware? The RT-BE82U does not appear to be supported by either Asus-Merlin or the GNuton fork of Asus-Merlin. This subforum (Asus-Merlin) discusses the Asus-Merlin firmware primarily. For discussions on stock Asus firmware for the BE series routers see the ASUS BE Routers & Adapters (Wi-Fi 7).

RMerlin, the developer of Asus-Merlin, has explained in the past how he gets the GPL's from Asus and that those GPL's are not always the same as those used in the Asus stock release firmware.

I get code directly from Asus, it's unrelated to what's released on their website. I have particular requirements that their developers need to meet when preparing the archives, like having the same code base for all models, which is rarely the case with their own firmware releases.

This has always been the case, each model always had its own separate GPL. It's impossible to share a GPL for more than one model, as each GPL contains precompiled pieces that only work for one specific device.

It depends. If you ask them for a GPL drop for a particular model, it will be for the same version that was used for that model's released firmware - which is what the GPL licensing requires them to do. The difference in my case is they build the tarballs for all models within a branch but all on the same version, so I don't need to maintain 20 parallel branches to handle 20 devices on 20 different codebase versions. Sometimes, that version will match a released firmware. Sometimes it will be a newer snapshot, depending on the point in time where they prepare those archives. But in terms of content, yes, that is the same code that is available in regular GPL drops. Just it might be from a more recent git point.

 

[RMerlin]

The GPL archive is different because it contains precompiled binary blobs for the proprietary bits and has all the confidential source files removed, while the firmware release is built directly from the full source code. So, it's normal for them to differ.

Basically the workflow goes like this:

- Compile official firmware off source code, and release that firmware
- Create a GPL tree off the source code, including only the portions that are for that specific model (the full Asuswrt source code takes dozens of gigabytes to cover every model and platform), inserting precompiled binary blobs into those prebuild/ directories, and removing any proprietary source file.
- Create an archive off that generated GPL source tree

ceventd is a Broadcom component that is unused by the firmware. It's probably included automatically by the Broadcom build system off the source code, but filtered by the GPL preparation process. There is a couple of such unused Broadcom components that slip into a release firmware, some of which are properly filtered out from the GPL archive.