SoylentNews is people
SoylentNews
Submitted via IRC for TheMightyBuzzard
The Federal Communications Commission's Enforcement Bureau has reached a $200,000 settlement with TP-Link in regards to selling in the US routers that could operate at output levels higher that allowed by FCC rules.
At the same time, TP-Link has also agreed to work with the open-source community and Wi-Fi chipset manufacturers to enable consumers to install third-party firmware on their Wi-Fi routers.
Source: Help Net Security
This discussion has been archived.
No new comments can be posted.
FCC Orders TP-Link to Allow Third-Party Firmware on Their Routers
|
Log In/Create an Account
| Top
| 16 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
serendipity, n.:
The process by which human knowledge is advanced.
(Score: 1, Interesting) by Anonymous Coward on Thursday August 04 2016, @04:32AM
So the FCC beats them in the head with a brick for "selling in the US routers that could operate at output levels higher than allowed by FCC rules. I'm assuming that's made possible by firmware. Now TP-Link has settled by way of fines and locking settings for power output. Wouldn't allowing third party firmware that restores that functionality put them right back in the bucket of "selling in the US routers that could operate at output levels higher than allowed by FCC rules.?
I can't tell if it's rabbit season or duck season these days.
(Score: 2, Informative) by Anonymous Coward on Thursday August 04 2016, @05:39AM
ThinkPenguin has another take on this. [thinkpenguin.com] It looks like this may actually cause more problems than it solves.
(Score: 2) by NCommander on Thursday August 04 2016, @05:57AM
I'm very much in two minds about this.
On one hand, I hate to see proprietary and binary blobs become even more common in networking equipment for most of the reasons listed in the thinkpengiun article. Being able to extend devices to do mesh networking and such generally requires the ability to play with the low level firmware and radio modulation stuff.
On the other, making it easy to manipulate the radio makes it trivial to make a 2.4Ghz radio bomb. RF interference is already a huge issue (ask any ham radio op), and making it trivial to exceed FCC limits means that we are in a scenario where I could easily break wifi in a large area by just loading a custom firmware. The fact is the power settings really need to be locked on a HW basis while not preventing arbiertary RF signals. Basically, you can transmit what you want as long as you're within the FCC limits for power and such.
Still always moving
(Score: 1, Touché) by Anonymous Coward on Thursday August 04 2016, @12:00PM
Yeah, but isn't it already trivial to create a "2.4GHz radio bomb"? Just defeat the door interlock on a microwave oven. With roughly 1kW of power, you probably don't even need to bend the frequency into the WiFi range (microwave ovens are usually a bit higher) to deafen any nearby WiFi devices.
(Score: 2) by Scruffy Beard 2 on Thursday August 04 2016, @04:42PM
Custom firmware should let you lower the radio output as well.
Though from my limited experience with CB radios, I know nobody does.
(Score: 2) by NCommander on Friday August 05 2016, @09:20AM
Well, lower is fine. And yeah, people using cheesed CB sets cause all sorts of fun bleedover. (Un)fortunately, CB is surronded by ham bands on both sides in the spectrum so it doesn't hugely effect most other radio operations.
Still always moving
(Score: 2) by sjames on Thursday August 04 2016, @06:36AM
The solution is to allow 3rd party software, but have the protected radio firmware refuse to go outside of FCC regulations. It would be easier if TFA had just said that.
(Score: 1, Informative) by Anonymous Coward on Thursday August 04 2016, @11:07AM
While a "proper" solution, the problem with this one is economic (specifically the "economies of scale"). The problem begins with the fact that there is not one single world-wide standard for power, frequency, and channel allocations.
Which means the chipset makers can:
1) make different chipset hardware, one each, for each different standard the world over (increasing prices on each version, because now each one is much a much lower volume production product;
2) make one single chipset that is software configurable to operate in each of the multitude of different world-wide standards. This option is what captures the economies of scale, one single software configurable chipset, is going to be by far less expensive to manufacture longer term than 100 different standard specific chipsets.
So the chipset makers are never likely to want to go to the "one per standard method".
Now, the same method applies to the router makers (e.g. TP-Link and others).
They can make one box, that depending upon what factory firmware they load, will operate in one of the 100 world standards, which means they also get economies of scale (make one generic piece of hardware, configure it by what software is shoved onto it at the end of the line).
Or they can make plural boxes, each with a different chipset hardware in it (thereby driving up their costs because they now have smaller runs of 'niche' products instead of a single large run of "all the same generic box".
So the economic incentive is pushing very hard towards the single wifi chipset, software configurable, and single route box platform, also software configurable, to keep the costs low. But that then violates the FCC rules because someone can, by loading different software, gain the ability to fiddle with the software configurability of the wifi chipset.
The only middle ground they have, and which they likely don't want to go because it means re-engineering their hardware, is to isolate the chipset from the main router CPU such that the main router CPU can't reconfigure it. But then they have to add the circuitry to actually configure the chipset (because the main CPU can't configure it anymore) which again drives their BOM cost up somewhat.
Which leaves open source in a no win situation. The economic incentives are "full-configurability" because that makes the most generic hardware. But that hardware is "against the FCC rules" so it has to be locked out from open source firmware, lest someone have the ability to violate the rules.
(Score: 2) by sjames on Thursday August 04 2016, @07:49PM
I am suggesting option 2 (the one that captures economy of scale). The modern chipset for WiFi includes a microcontroller running a signed binary blob. Each regulatory domain gets it's own version of that blob. So in the U.S., the (possibly 3rd party) OS loads the signed blob into the radio chipset. The chipset checks the signature and if it is correct, in initializes and sets an appropriate status code.
In another domain, a different blob is loaded.
Worst case if some regulator has a stick up it's backside, a few jumpers get strapped on the board to tell the chipset which signed blobs are acceptable.
In cases where the radio chipset is part of the CPU, the CPU itself likely has a protected domain that the OS can't get at. I know ARM supports that as does x86. I think MIPS does too. Many flash chips are also segmented and have blowable fuses to prevent a portion of them from being re-written. So, bootloader gets it's own segment and OTP fuse gets blown. Main OS gets another segment that remains re-writable. Bootloader establishes the trust zone that controls the hardware, then loads the OS (whatever is flashed into the OS portion of the flash). As a side benefit, the bootloader can have a protected re-flash/diagnostics function that can't be erased, making bricking practically impossible short of a soldering iron.