Comment by ktta | Hacker News Reader

Comment by ktta | Hacker News Reader

Parent Full thread

Open source software on routers is a little complicated.

FCC requires home router manufacturers to prevent users from modifying transmit settings (primarily to prevent interference with weather systems - which 5G is also going to mess with). While the router manufacturers themselves might not provide features to modify the parameters, allowing third-party open source firmware opens them upto liability, because third-party firmware -- almost all of which are open source, can provide users with features that allow changing the transmit parameters. This is because the radio operation is controlled by the OS (most of these have linux on them), and the parameters are to be included in the same firmware blob as the OS.

FCC is not the problem here either. FCC saw the quick-fix that some manufacturers took, like TP-Link, which is to block any third-party firmware. So they required TP-Link to reverse their decision to prevent installation of third-party firmware. Then what's the solution?

The best way to prevent allowing consumers to change the transmit settings, while allowing open source firmware meant for the rest of the board (where all of the security issues arise), will require having different flash chips - one for most of the firmware, and a separate on for the storage radio parameters. This route is what Linksys is taking.

Personally, I doubt this is a good enough solution. Board designs today use a single SoC that does everything. So I'm not sure how they think storing the transmit settings on a different flash chip will prevent the firmware from using different parameters. Any design that is more complex than the two flash chip solution will require a lot of reworking of designs, because most board designs basically consist of a few components: the SoC, the flash and RAM. Nothing else.

Apart from the re-working of existing designs, there's another problem. The problem is the BOM constraints router makers face, since they are always in a race to the bottom price-wise. Adding additional chips, introduces cost and complexity, which they don't want to go through.

The solution is that there is no preemptive solution, any more than there is a preemptive solution to using an axe dangerously. You can build a transmitter out of a Raspberry Pi and a short length of wire; for extra credit, you can buy a cheap amplifier and really go to town, but the simple fact you can strobe a GPIO pin fast enough to transmit on unauthorized frequencies is the final nail in the coffin for any plan to restrict broadcasting by restricting radio sales.

The enforcement comes down to this: If you transmit in an obnoxious way and you annoy someone, you get squashed. If you kill someone, you get squashed harder. That doesn't bring the dead back to life, but sending someone to prison for killing someone else with an axe doesn't bring the dead back to life, either.

1. FCC has only started to require home router manufacturers to prevent users from modifying transmit settings some years ago, we have lived quite long without this ban and had no problems it is supposed to prevent. 2. Put detailed transmit settings modifying tool right in the web UI of default firmwares of all the routers and you'll see just a negligible portion of the userbase ever touching it. Most of the people don't even know what a megahertz is, let alone have any clue on how to tweak transmit settings for any kind of benefit.

The FCC is certainly the problem in this case. If someone modifies the product to break the law the person is at fault not the manufacturer. That someone could do modify their radio to do bad things shouldn't stop me from modifying mine to do good things.

Would you also say that Uber doesn't violate taxi laws or AirBNB doesn't violate zoning laws, and it's just the Uber drivers and AirBNB hosts who are using the products to violate the law? What's your responsibility when you hand someone a loaded gun and it goes off?

> What's your responsibility when you hand someone a loaded gun and it goes off?

Zero, as long as the person:

(1) Knew it was loaded

(2) Voluntarily accepted to receive the gun.

> Zero, as long as the person:

In this analogy the gun going off broke a law. So you voluntarily handed somebody a loaded gun - who then committed a crime with that gun.

Obviously context matter - but you can bet the police will be asking why you gave that gun to them.

When a router ships you can't select a licensed band. This is a different concept than "product does something bad" this is "is the manufacturer responsible when someone modifies the product to do something bad".

Clearly not, the person that knowingly modified it to do something illegal is at fault. Preventing anyone from modifying anything is a backwards response to the real problem: the guy that wants to do the illegal thing.

The same argument can be made with any other tools in existence. Don't blame the tool for doing something bad, blame the user.

That is a different argument than you imply, please read the existing sibling comment chain to see how as it's pretty much the same discussion.

Really it seems like the radio ASICs themselves should be adding a little bit of embedded flash or OTP memory. But barring that, as the storage requirements of routers increase (having already moved from NOR to NAND flash) we may eventually reach the point where a router includes a BGA SSD whose controller can enforce permanent read-only permissions on a partition that stores RF parameters.

But what do you do when it's the radio firmware itself that has a security for and the vendor stopped patching their devices? It's a pain in the ass to secure a closed source binary blob.

Example: https://hackaday.com/2019/09/05/esp8266-and-esp32-wifi-hacke... what if Espressif dropped support for these a while ago? You couldn't securely use these in some scenarios without reverse-engineering the binary blobs and patching the flaws. And I can't imagine how many of IoT devices out there use that chip or a derivative.

Those Espressif blobs are running on the same processor as the application/OS and are responsible for a lot more functionality than the typical radio firmware for a Broadcom/Qualcomm/Mediatek WiFi NIC that connects over PCIe. That firmware is also entirely different from the RF regulatory data I was talking about; the regulatory data should be in a ROM somewhere but the WiFi firmware generally needs to be stored alongside and updated in lockstep with the operating system's driver for the WiFi device.

Most routers have the SoC integrating the radio chip, and running firmware and the OS on the same silicon.

Wireless router SoCs usually have at most one radio integrated, and the 5Ghz radio is still usually attached over PCIe. And even the integrated 2.4Ghz radio's firmware is running on entirely separate processor cores and in a different memory address space from the application processor.

I did not know that the firmware for the radio is running in a different context (memory space/processor). I assumed they would, to save cost, run everything together.

Reply on news.ycombinator.com