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