[LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]

[Dave Taht]

The linked document below is the same document we attacked, I thought
successfully, last year,

http://www.computerworld.com/article/2993112/security/vint-cerf-and-260-experts-give-fcc-a-plan-to-secure-wi-fi-routers.html

with the ultimate response from the fcc being

https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates

Merely being asked to describe how the regdb works is all I see as the
current FCC requirement. More than one manufacturer has got through
this process since. Also, the context of that whole original debate
was a dispute with tp-link, which only came out after the legal dust
had settled.

http://arstechnica.com/information-technology/2016/08/fcc-forces-tp-link-to-support-open-source-firmware-on-routers/

On Wed, Nov 16, 2016 at 2:15 PM, Simon Wunderlich
<simon.wunderlich at open-mesh.com> 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.
>
> 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. "
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org