| From: James Knott via talk <talk@gtalug.org>
| On 08/01/2016 05:27 PM, D. Hugh Redelmeier via talk wrote: | > So the original problem remains: how can TP-Link prevent existing | > hardware from generating too strong signals if it cannot control the | > firmware? | | The limits might be hard coded elsewhere.
No, they are not. That's the problem:
1) FCC has made a new rule that manufacturers are to prevent customers from breaking the signal strength limitations. They've had such rules for a while, but on home routers, adding power causes more interference and cross-talk, so sane vendors tend to keep
[In-line comments] On 01/08/16 10:19 PM, D. Hugh Redelmeier via talk wrote: their power low. Some few will try reducing power when they see interference. TP-Link seems to have shipped with an illegal power setting straight from the factory.
2) current and past hardware is "dumb" and depends on software to do correct configuration (sensible from an engineering standpoint)
Bonus complexity: the power limits and channel frequencies depend on the country you are currently in. If the device has to enforce this then it needs to know the country and probably not trust the user to get it right. Second best: sell a different model in each country.
The open source codebases typically uses the Linux CRDA mechanism, which is cryptographically signed by the kernel maintainer, John Linville, and allows the owner to set the country, which in turn sets the power, channels allowed and radar sensitivity . See http://linux.die.net/man/8/crda and https://wireless.wiki.kernel.org/en/developers/Regulatory
Alternative solutions:
a) customers must not be allowed to replace the software (pretty easy and cheap; works on existing hardware)
b) new hardware with "smart" radios that know not to accept violating parameters (this requires a new geofneration of devices, ones that are more complicated and likely more expensive; probably one device per jurisdiction).
We do this in software, using the CRDA for good stuff and fixed tables in some proprietary crap. Almost all wi-fi chips are "thin" and require everything to be done in software by the controlling CPU.
c) some kind of sandboxing of user-supplied firmware. This seems to be mentioned in the article. This is probably the most complicated solution. It would probably increase the engineering and manufacturing cost, all for a small minority of customers. And it actually limits the reach of the third party firmware in unintended ways.
The FCC asked for cryptographically signed safety-critical software bits: we have part of that, but the vendors and WRT folks may need to do more, and perhaps get regulatory approval for the CRDA in general.
z) ignore the FCC.
Only (a) can be retrofitted on existing hardware. TP-Link did the obvious thing. I hate it (as a customer who actually bought one of their devices to run OpenWRT). But it really is a choice between (a) and (z) on existing devices.
Vendors previously claimed that the FCC's old rulings required (a), and that if you wanted a bug fix, you had to buy a new router from them. TP-Link seems to be the first company that actually implemented (a), but did it to protect not-legally-compliant software from being made compliant (;-)) You can imagine the reaction at the FCC! --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain