What does "non-free binary blobs" mean?


I am doing my research to compare OpenWrt and DD-WRT.

Some articles point out that OpenWrt does not allow "non-free binary blobs" so that it does not support as many routers DD-WRT supports.

The reason is that some router manufacturers want to install non-free binary blobs in their routers. Therefore, OpenWrt cannot support those routers.

Could someone explain to me what is "non-free binary blobs"? Why do routers need "non-free binary blobs"?


Non free refers to no freedom to read and modify the code, such as the freedoms given by the GPL or BSD or other free software licenses. "Binary blob" means it's the output of a compiler, machine code, very hard to understand what it does or to modify it.


@dlakelan Thanks. So, what do some routers need to install "non-free binary blobs" while other routers do not need to install "non-free binary blobs"?

Mostly because some routers use hardware that isn't supported in an open way by the manufacturer. If the manufacturer won't document how to write drivers then the free software driver writers are just stuck, and only the "binary blob" provided by the manufacturer of the hardware can run the device.


@dlakelan "non-free binary blobs" in routers are similar to drivers we install in our computer to communicate with the specific hardwares, right?

If this is true, is "non-free binary blobs" also a security issue if a manufacturer installs some software to monitor our online traffic? Like which websites we visited.

Also, is it safe to say if OpenWrt supports a particular router, then this router does not have "non-free binary blobs" because OpenWrt does not allow "non-free binary blobs"?

Could be, but that seems unlikely when it comes to kernel binary blobs. but it could be more of a security issue when there are remote execution bugs, for example someone can send a "magic packet" and the binary blob will crash and cause the kernel to do something bad.

But I have a feeling that "non-free binary blobs" is provided by chip manufacturers. For example, if TP-link routers use "non-free binary blobs" and those routers use Intel Chipsets, "non-free binary blobs" is actually provided by Intel not by TP-Link. TP-link possibly does not have a way to modify "non-free binary blobs".

correct, it's the chipset manufacturer not the router manufacturer

Also, when is "non-free binary blobs" installed? Is it installed before we install OpenWrt or is it installed after we install OpenWrt?

Usually, we install drivers after we install the operating system.

non free binary blobs are needed for the hardware to run. OpenWrt mostly just doesn't run on this hardware. DDWRT comes with those blobs built in if they are needed.

@dlakelan I see. So, how does DDWRT get those non free binary blobs?

Do Chipset manufacturers provide those non free binary blobs to DDWRT?

Then, when we install DDWRT, it sees which Chipset is used by a particular router and then it installs "non free binary blobs" for that Chipset?

OpenWRT and DDWRT are kind of "firmwares" so they get flashed to embedded devices and they include everything needed for basic functions at that time, so normally wouldn't be "installing" them, just "including" them and yes they come from the manufacturer, though usually probably get extracted from the router/ap manufacturer's firmware rather than coming directly from the chipset mfg? I'm not really sure.

Actually, I don't think this is true anymore in terms of the number of supported routers. I don't have numbers to back this up, but I am under the impression that OpenWrt supports way more routers than DD-WRT. However, this comes with a caveat for some devices...
Devices that require "non-free binary blobs" are not well supported by OpenWrt. By that I mean that certain features may not be available/functional or may have limited performance.

  • For example, OpenWrt supports many routers with built-in DSL modems, but the modem itself in many devices is not operational when using OpenWrt. Only a certain set of devices have supported DSL modems because of the non-free binary blobs issue.
  • Another example is the wifi chipset on certain devices. Take the Linksys E3000 which has a BCM47xx chipset. The device works just fine as a wired router (albeit slow due to its age/limited hardware), but the wifi performance is miserable because of the driver (basically it has a barely functional open source driver rather than the properly optimized closed-source driver from Broadcom).

Yes, actually. At least this was the case in the past. I am not sure about the current status of that project -- it seems to have languished quite a bit, and it has lost at least one prominent developer who has moved over to OpenWrt.

Those blobs can be extracted from the manufacturers original firmware.

Sure, there is nothing that stops someone from extracting the blobs from the original firmware, but then embedding thees blobs into another firmware is not trivial. There are likely kernel version and other dependencies which means that you can't arbitrarily include this code in a build with a different kernel version. And, that not withstanding, the whole idea that the OpenWrt Project doesn't use closed source binary blobs makes the extraction moot.

That's why android and other sw heavily relying on "harvested" blobs is stuck on old kernels and system libs forever...

1 Like

I think you entered two things here:

  • I don't see why a private person ("someone") cannot do so for their own device - again if the blob is even cross-compatible if successful in copying
  • But in some cases, doing for the purpose of bundling (i.e. into OpenWrt) so would violate the license (and in some nations, the law)...which to prevent...they likely want money :money_with_wings: to issue said license :white_check_mark:
  • I'm also sure doing so would be reverse engineering, "decompiling the firmware", etc. - which I'm also sure some OEMs restrict

This was fixed in...Android 9 or 10 (I believe). OEMs can send updates to the OS much easier with their blobs staying in place.


Nailed it!

For the record, when I said that there is "nothing that stops someone" - I meant that on a technical level (and that also assumes that there aren't technical countermeasures that cannot be worked around). There are plenty of things that stop the use of these blobs, including, as @lleachii said, legal considerations.