4 ms·

Even with the WRTs, the firmware is probably built by the manufacturer. Try finding the provenance of who wrote the source code and where they live. AFAIK, that

Even with the WRTs, the firmware is probably built by the manufacturer. Try finding the provenance of who wrote the source code and where they live. AFAIK, that's not possible. So you have a router built with Chinese components (all of the ones anyone here can afford) with closed and "open" firmware built by them. I bought one of those GL.inet "open" routers and the WRT packages bricked it, so I have a choice of reverting or flashing from the factory (which appears to be a link to HK). That's probably 99.99% of use cases. They're in your base and they always have been.

rekabis 2y ago
> Even with the WRTs, the firmware is probably built by the manufacturer. Say you know nothing about router firmware without saying you know nothing about router firmware. OpenWRT and DD-WRT and other open-source third-party firmwares are THIRD PARTY firmwares. They have no connection with the manufacturer whatsoever.
- hindsightbias 2y ago
  I just looked at 10 different openwrt data entries: > WikiDevi URL: https://wikidevi.wi-cat.ru/TP-LINK_Archer_C2_v3.x https://wikidevi.wi-cat.ru/TP-LINK_Archer_C2_v3.x Every one had a .ru domain. How do you know, exactly, who built it? GL.inet builds their own WRT package. It's a "feature".
  - rekabis 2y ago
    > Every one had a .ru domain. Brand-new to the Internet, are ya? Just because you cherry-pick Russian informational sites doesn’t mean that third-party firmwares have any connection to Russia whatsoever. Third-party firmwares are open-source projects, worked on by tens of thousands of volunteers from around the planet, and frequently have ZERO CONNECTION to any one hardware manufacturer. There are some collaboration efforts, when a particular manufacturer decides to adopt an open-source firmware as the exclusive firmware for their own hardware, but that simply means the hardware is fully unlocked for any third-party firmware that wants to be adapted for that hardware. These manufacturers just decided that they had no desire to f**k over the consumer by locking them into custom-made firmware. For example, I believe Turris https://www.turris.com/ https://www.turris.com/ takes a stock, latest copy of OpenWRT and makes a few tweaks to extend its capabilities for additional, server-like features.
- wtallis 2y ago
  One slight correction/clarification: "firmware" in this context can sometimes be referring specifically to the firmware that runs on the WiFi radios, rather than the whole Linux OS running on the application processor. 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. Even when running OpenWRT, you're still relying on that closed-source WiFi firmware to have a working radio. (The closest thing to an exception: https://www.candelatech.com/ath10k.php https://www.candelatech.com/ath10k.php) WiFi NIC firmware is a much smaller attack surface than the whole Linux OS.
  - rekabis 2y ago
    > "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.
    - wtallis 2y ago
      > 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.

rekabis 2y ago

> Even with the WRTs, the firmware is probably built by the manufacturer. Say you know nothing about router firmware without saying you know nothing about router firmware. OpenWRT and DD-WRT and other open-source third-party firmwares are THIRD PARTY firmwares. They have no connection with the manufacturer whatsoever.

hindsightbias 2y ago
I just looked at 10 different openwrt data entries: > WikiDevi URL: https://wikidevi.wi-cat.ru/TP-LINK_Archer_C2_v3.x https://wikidevi.wi-cat.ru/TP-LINK_Archer_C2_v3.x Every one had a .ru domain. How do you know, exactly, who built it? GL.inet builds their own WRT package. It's a "feature".
- rekabis 2y ago
  > Every one had a .ru domain. Brand-new to the Internet, are ya? Just because you cherry-pick Russian informational sites doesn’t mean that third-party firmwares have any connection to Russia whatsoever. Third-party firmwares are open-source projects, worked on by tens of thousands of volunteers from around the planet, and frequently have ZERO CONNECTION to any one hardware manufacturer. There are some collaboration efforts, when a particular manufacturer decides to adopt an open-source firmware as the exclusive firmware for their own hardware, but that simply means the hardware is fully unlocked for any third-party firmware that wants to be adapted for that hardware. These manufacturers just decided that they had no desire to f**k over the consumer by locking them into custom-made firmware. For example, I believe Turris https://www.turris.com/ https://www.turris.com/ takes a stock, latest copy of OpenWRT and makes a few tweaks to extend its capabilities for additional, server-like features.
wtallis 2y ago
One slight correction/clarification: "firmware" in this context can sometimes be referring specifically to the firmware that runs on the WiFi radios, rather than the whole Linux OS running on the application processor. 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. Even when running OpenWRT, you're still relying on that closed-source WiFi firmware to have a working radio. (The closest thing to an exception: https://www.candelatech.com/ath10k.php https://www.candelatech.com/ath10k.php) WiFi NIC firmware is a much smaller attack surface than the whole Linux OS.
- rekabis 2y ago
  > "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.
  - wtallis 2y ago
    > 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.