[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