[In-line comments]
On 01/08/16 10:19 PM, D. Hugh Redelmeier via talk wrote:

| 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 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