Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> "firmware" in this context can sometimes be referring specifically to the firmware that runs on the WiFi radios

Congrats, you have just identified DD-WRT and OpenWRT.

> The WiFi firmware is closed-source and comes from the silicon vendor rather than the router OEM: Qualcomm, Broadcom, or Mediatek, not TP-Link, ASUS, Netgear, etc.

Never heard of the term “driver”, have you? Look it up. It’s wild. Windows uses them, and so does Linux and other operating systems like DD-WRT and OpenWRT.



> Congrats, you have just identified DD-WRT and OpenWRT.

> Never heard of the term “driver”, have you? Look it up. It’s wild. Windows uses them, and so does Linux and other operating systems like DD-WRT and OpenWRT.

Please don't post with this kind of attitude, especially when you're so thoroughly wrong.

Look up the term "application processor"; I mentioned it previously but you must not have recognized that it was a concept you are unfamiliar with. This is the ARM (or formerly MIPS) processor that in a router will be running Linux, or on a phone would be running Android or iOS. The AP's CPU cores are not the only processor cores that will be found in the system. Separate from the AP and often at the far end of a PCIe link (and hopefully also an IOMMU) are the WiFi NICs, which have their own embedded processor cores. These embedded cores are not running Linux and instead are running proprietary firmware that is closely tied to the specific hardware. (In a phone, the cellular baseband will have its own processor core(s) running separate code from the AP's OS.)

Linux has its drivers for the WiFi NICs, and those drivers run on the AP cores. Typically, the first responsibility of the Linux driver is to retrieve the correct firmware from storage and transmit it over PCIe to the WiFi NIC so that the processor cores embedded in that NIC can boot up and start running that firmware on cores and a memory address space that is completely separate from what the Linux OS on the AP can directly interact with. The firmware must be uploaded to the NIC by the AP because the NIC typically doesn't have flash memory to store its own firmware, only volatile RAM, and because the firmware version usually must be precisely matched to the driver version running on the AP. This is in contrast to eg. SSDs, which store their own firmware (because they naturally have plenty of non-volatile storage) and expose standard interfaces for drivers to interact with rather than having tight version coupling.

Exactly what the firmware running on the WiFi NIC does will vary between devices. It can often be inferred by inspecting the Linux driver to see what it doesn't do on the AP. Common functionality handled by firmware running on the NIC includes selecting transmission rates and power levels, and handling frame aggregation.

You can readily inspect the filesystem of an OpenWRT image and you'll find the binary blobs that are the firmware which will be sent to the NICs as part of the Linux driver initializing. What you won't find is that binary blob code executing on the AP in any userspace process or kernel thread.

And if you're still arrogantly confused: the WiFi firmware is not the same thing as the Linux driver. In all WiFi hardware that uses firmware running on the NIC (which includes all WiFi hardware supporting anything newer than 802.11n), the WiFi NIC's firmware is closed-source. This is independent of whether or not the Linux driver is closed-source, because the Linux driver is a different piece of code running on a different processor.

All WiFi devices that have received the Free Software Foundation's "Respects your Freedom" certification are limited to 802.11n because those are the newest devices that don't run proprietary blobs on their own processor cores. OpenWRT has looser requirements and tolerates proprietary blobs as long as they don't need to run on the AP as part of the Linux system. The typical setup for an OpenWRT device is an open-source Linux driver communicating over PCIe with closed-source code running on the WiFi NIC.

The Candela Technologies page I linked to is an example of closed-source firmware to run on the WiFi NIC, paired with an open-source Linux driver to run on the AP. This is one of the few examples of the closed-source firmware not coming directly from the creator of the WiFi chip. Both the WiFi firmware and the Linux driver had to be modified in order to add the features Candela Technologies needed. They were able to acquire a license from Qualcomm to modify and redistribute the WiFi firmware, but not to open-source that firmware. The Linux driver was already open-source so no special license was required for that side of their feature enablement.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: