I think however what they ultimately do want to do is of course make a 1:1 parity between hardware and the license granted. This is a very good thing with regards to protecting spectrum, but it seems to possibly not reflect the trend to push more and more of signal processing into firmware and software. Will it increase parts counts and the bill of materials? Perhaps it has been too optimistic make one globally available physical product supplemented with a software tweak for each locality.
Maybe I'm misunderstanding, why is it an issue if the signal processing is done in firmware? Isn't the idea of firmware that it's factory set and read-only?
I've been using Tomato-USB on Asus hardware for several years now... the current Asus firmwares aren't bad though the early ones were pretty horrible. I actually prefer Tomato and similar options, I used openwrt for my home office (routerstation pro) for a few years as well. Being able to run third party software is essential for security updates given that the manufacturers rarely offer more than 1-2 updates and almost never after the first year of a product introduction.
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.
I also like Tomato on ASUS hardware, but as far as updates go, it seems little-to-no better than using stock manufacturer firmware. There is no central development project, and there is no one who ensures that new updates work on existing hardware. It seems like a few people put together some builds that work on what they have, toss them over the fence, and everyone else is left scrounging for what works on their particular hardware.
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...?
Dunno... It's pretty hard to brick the router beyond recovery via tftp... That said, I'm no expert on the issue... I've been using the Shibby Tomato-USB releases myself, but tbh don't update as much as I should.
Looks like there's no third party release for the RT-AC3200 yet, though the mfg release is modified tomato.
> why is it an issue if the signal processing is done in firmware? Isn't the idea of firmware that it's factory set and read-only?
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.
There are regulations about what frequencies and at what power different devices may broadcast. Currently, those implementations (and hence regulations) are done/enforced in some combination of hardware and software, but mostly hardware. Implementation is moving to software, so updating the OS allows the user to override those regulations. The FTC is not thrilled about this.
Yeah, I understood that, I was just confused as to why he or she mentioned firmware along with software because I thought firmware can't be modified by users like software can. I was wrong in thinking that though.
But when the day comes that SDR's which can transmit from 0-10GHz are in every device you buy, all the FCC will be able to do is rubber stamp these devices as 0-10GHz SDR's, which are actually very capable of severe interference:
https://www.youtube.com/watch?v=CXv1j3GbgLk
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.
> Our original lab guidance document released pursuant to that Order asked manufacturers to explain “how [its] device is protected from ‘flashing’ and the installation of third-party firmware such as DD-WRT”. This particular question prompted a fair bit of confusion – were we mandating wholesale blocking of Open Source firmware modifications?
> 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 irony is that DD-WRT never touched anything within FCC legislation – it still uses the vendors' proprietary WiFi firmwares for the actual radios. It just makes everything around that suck less.
The worst you can do with DD-WRT is intentionally set a wrong country code.
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.
> Why does this need any kind of new change in the first place?
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.
"So, today we released a revision to that guidance to clarify that our instructions were narrowly-focused on modifications that would take a device out of compliance."
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?
Nobody will probably see this, but this is my take on the undertone I get from reading this:
"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.
20 comments
[ 3.3 ms ] story [ 58.1 ms ] threadTomato, 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.
> 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.
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.