Clearing the Air on Wi-Fi Software Updates
fcc.gov
fcc.gov
> We were not, but we agree that the guidance we provide to manufacturers must be crystal-clear to avoid confusion.
Can you feel the wind off of that backpedaling?
There's no possible way they asked how devices were "protected" from "third-party firmware such as DD-WRT" while not expecting blocking of Open Source firmware modifications. It sounds a lot more like they got too much backlash: "...no, of course that's not what we meant [looks around nervously] you believe us, right?".
While this might result in a desirable outcome, I think it would have come across as far more genuine if they'd directly acknowledged that they originally suggested blocking all third-party firmware, and subsequently decided that they'd need a more nuanced approach. That, at least, would not come across as a (transparently bad) spin attempt.
Why does this need any kind of new change in the first place? The FCC can certainly go after people who actually transmit in violation of FCC regulations, and they do, no matter what device they use to do so.
The worst you can do with DD-WRT is intentionally set a wrong country code.
Which lets you transmit on unauthorized frequencies, such as channel 14.
But you can hardly do that by accident.
Exactly, and plenty of closed source router firmwares expose the same option. And radios (Japanese radios can listen on German police frequencies, I think), etc. pp.; basically everything with an antenna that's sold in more than one country.
The same reason as other FCC regulations, so you don't inadvertently pollute part of the spectrum with either transmissions or noise? One device might not be a problem, but it's potentially a slippery slope with more and more software defined devices. It really shouldn't be that hard to come up with a solution either, even if it's just slightly more resilience.
The other solution might be to certify the firmware, so for instance it doesn't default to noncompliant settings when you flash, but that seem like a bigger mess.
Tomato, dd-wrt, openwrt and the like allow me to control my hardware and use it for the life of the hardware, not the year of updates the mfg gives.
And are you really going to experiment with building it yourself when you're talking about your Internet router? What do you do if it bricks?
I've been thinking for some time now that the only sensible way forward is a device that runs plain Debian stable, something Raspberry Pi-like, with a USB dongle or two and a plain Ethernet switch. That way, keeping up-to-date is as simple as `apt-get upgrade`. And with a few SD cards, one can easily keep multiple working system images, clone them, and swap between them for testing and upgrades. This situation in which it's even possible to brick a router seems like primitive savagery and madness.
But, not having a DD-WRT/OpenWRT-compatible router, maybe I'm just missing out...?
Looks like there's no third party release for the RT-AC3200 yet, though the mfg release is modified tomato.
There are multiple levels to this, and it varies with chipsets. Take for example, a very basic crappy chipset like the TI WL127x transceiver series. This chipset would be the lowest level. It is what implements the lowest level of radio signal processing above the hardware. That chipset has its own firmware. That's very small. Typically, less than 128kbytes. But it is rarely factory set or read-only. Rather, it is a binary blob that is loaded on to that chipset by a linux kernel wifi driver. The driver is typically not a binary but source code that is part of the linux kernel. That blob, driver, kernel, and rest of the system are then part of a "firmware image" that is flashed on to your router/phone/embedded device. It is reasonably common to want to modify and customize that firmware image. Hence forums like xda, cyanogen, etc. The binary blob is the only part that isn't very common to modify, but even then, given the high rate of implementation defects in that blob, one wishes source were available for that as well so that it could be better controlled.
The reason they want to regulate the software is because regulating the hardware is soon not going to be sufficient.
Hopefully one day we can use extreme versions of beam forming (e.g. the pCell) to replace the need for RF regulations and switch to space based multiplexing as opposed to frequency based multiplexing.
With the advent of software defined radio, how is it even possible to draw such a line between the part of firmware "that can take a device out of compliance" and the part of firmware that cannot?
"Manufacturers are lazy, and hardware/driver implementations are often buggy and not sufficiently restrictive. Lobbying the manufacturers didn't work[citation impossible], so we might need to block DD-WRT et al. on devices that are sufficiently enough that they freely allow firmware like DD-WRT (and OpenWRT) unmitigated access to the RF chip's parameters via an insecure driver."
Of course they had to be much nicer and much more opaque than that, so everyone got confused.