[LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
David Lang
david at lang.hm
Thu Nov 17 08:26:35 PST 2016
On Wed, 16 Nov 2016, Simon Wunderlich wrote:
> Hi David,
>
> On Tuesday, November 15, 2016 4:49:40 PM CET David Lang wrote:
>>> Well, we are. We can't change the fact that the devices need to be locked
>>> to be sold in the US. But if you google a little, you will find a lot of
>>> patches for various Open Source projects signed by @open-mesh.com mail
>>> addresses (LEDE, Linux, hostapd, etc) ... Feel free to compare that with
>>> other WiFi vendors. I don't think we are doing that bad. :)
>>
>> except that they don't need to be locked down to be sold in the US.
>>
>> The FCC posted a proposed rule that would require such a lockdown, but then
>> have repeatedly made public statements that they do not intend to prevent
>> different firmware from being loaded on the devices and the proposed rule
>> that would have required lockdowns have basically been stopped.
>>
>> However, multiple vendors are imposing restriction and claiming that the FCC
>> is requiring them, even after the FCC says that it's not.
>
> You are right, the FCC doesn't explicitly requires to prevent third-party
> firmware loading anymore. However, they still require to explain how a vendor
> makes sure that US RF limits are not violated [1]. Since a third-party firmware
> can be anything including a firmware with a patched ath9k where DFS is disabled
> etc, we (as Open-Mesh) can't really prevent that those RF limits are violated.
> Thus we can not give a convincing explanation there, and the situation stays
> the same.
>
> If you have any constructive idea, I would love to propose it internally.
I'll point out that TP-Link got a slap on the risk for their actions in blocking
all firmware updates.
http://arstechnica.com/information-technology/2016/08/fcc-forces-tp-link-to-support-open-source-firmware-on-routers/
In that document, and in the post made at the same time (
https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates
) the FCC is explicitly saying that they don't want the vendors blocking DD-WRT
and similar.
I'll also point out that the FCC documents are not RFCs, the wording is not as
precisely defined. When they ask what measures are being taken to block the
devices working out of frequency, they are not asking you to make the devices
impossible to operate improperly, no matter what (something that is impossible)
I went through a similar set of issues back in the '90s with two-way radios. The
FCC was requiring that the manufacturers block using the radios on inappropriate
frequencies, and manufacturers were doing things to lock down the programming
software that was used to reprogram the radios to other frequencies.
But what has happened is that the manufacturers now have lock codes and/or
jumpers (including 0-ohm resisters) that allow people to unlock the radios and
program them (and the programming has largely been cloned with open-source
software like chirp)
The FCC, in practice, recognizes that people going to extrordinary lengths can
bypass reasonable restrictions and don't hold the manufacturers liable for them
doing so.
The fact that OpenWRT, LEDE, DD-WRT, etc now all default to the least common
denominator when a country code is not provided means that all the alturnative
firmware is sane by default, you have to go to extrordinary lengths to be
illegal.
And someone going to such lengths could just buy the non-locked down version of
the equipment on e-bay (or other websites) and have it shipped to them anywhere
in the world.
David Lang
> Thanks,
> Simon
>
> [1] From https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g
> %3D%3D&desc=594280%20D02%20U-NII%20Device%20Security
> %20v01r03&tracking_number=39498
>
> "Describe, if the device permits third-party software or firmware installation,
> what mechanisms are provided by the manufacturer to permit integration of
> such functions while ensuring that the RF parameters of the device cannot be
> operated outside its authorization for operation in the U.S . In the
> description include what controls and/or agreements are in place with
> providers of third-party functionality to ensure the devices’ underlying RF
> parameters are unchanged and how the manufacturer verifies the functionality. "
More information about the Lede-dev
mailing list