[GTALUG] FCC "forces" TP-Link to enable open source on their router(s)

David Collier-Brown davec-b at rogers.com
Wed Aug 3 07:57:11 EDT 2016


[In-line comments]
On 01/08/16 10:19 PM, D. Hugh Redelmeier via talk wrote:
> | From: James Knott via talk <talk at 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 at spamcop.net           |                      -- Mark Twain

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20160803/eb72285c/attachment.html>


More information about the talk mailing list