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.wunderl...@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@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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
