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. "
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev