We really need to find out what the new FCC requirements are.
People have been claiming that the FCC requires all sorts of lockdowns that they
don't actually require for decades (when I first got into Ham Radio, we were
hearing that any radio able to operate on the business bands had to be locked
down to prevent the owner from changing it's frequency. It wasn't true)
If they are saying that the RF portion can't be modified in a Software Defined
Radio, that would be somewhat reasonable, saying that the software implementing
the 802.11(whatever) protocol on that RF portion must be locked down is less so,
and saying that the main OS on the router must be locked down is completely
unreasonable.
I would be surprised if they required that the OS can't be changed.
As for the implementation of the 802.11(whatever) protocol, I would be surprised
if they required this to be locked down, but not dumbfounded
now that I've finished the rant, reading the statement quoted on that wiki page:
Applications for certification of U-NII devices in the 5.15-5.35 GHz and the
5.47-5.85 GHz bands must include a high level operational description of the
security procedures that control the radio frequency operating parameters and
ensure that unauthorized modifications cannot be made.
All that it is talking about is the radio frequency parameters.
The followup/clarification is again talking about the RF parameters.
Remember, when the FCC is talking about a 'device', they are talking about the
radio, not the entire computer that has a radio as part of it.
According to the background, they are worried about interference with radar, so
this could mean that the firmware needs to have a mechansim to detect the radar
and not transmit on that frequency, but this is only a few channels. You could
still have an opensource, non locked down firmware that just didn't give you the
option of using those channels, and a signed firmware that did.
This does not require secure boot or any of the other lockdown methods that are
being talked about on that page. I hope these are not the "official" openwrt
recommendations (and if they are, why are they not on an openwrt page?)
David Lang
On Tue, 9 Dec 2014, Eric Schultz wrote:
Dave,
Thanks for the quick response and I appreciate your passion.
No one here wants Secure Boot or DRM at all. I personally find the
idea abhorrent and no one at prpl wants it. The difficulty is figuring
out how companies can comply with the regulation in a way that doesn't
require hardware be locked down. I wish I could avoid ever thinking of
this topic but unfortunately, if companies don't find a solution that
fulfills the FCC's requirements, they're going to go with DRM. I want
to see if we can give manufacturers a solution that avoids DRM
entirely.
I'd be happy to learn more about the make-wifi-fast effort and to see
how we can facilitate it's success.
Thanks a ton,
Eric
On Tue, Dec 9, 2014 at 11:49 AM, Dave Taht <[email protected]> wrote:
On Tue, Dec 9, 2014 at 9:11 AM, Eric Schultz
<[email protected]> wrote:
All,
I work for the prpl Foundation, an open source foundation organized by
a number of companies, most related to MIPS. One project we work with
externally is the OpenWrt project. Recently one of our members
mentioned a new FCC requirement (described at
http://wiki.prplfoundation.org/wiki/Complying_with_FCC_rules_on_5ghz_wifi)
which requires wifi hardware devices to restrict modifications in ways
that were not previously required. Some of the suggestions the company
had internally for complying would be to use features like Secure Boot
and other types of DRM-like mechanisms to prevent routers from being
modified. This obviously would be quite bad for the OpenWrt ecosystem
It would be bad for everyone. Worse, since the research contingent
making progress on keeping wifi working in the first place in the face
of enormous growth, is centered around the ath9k chipset, additional
rules and regulations centered around DRM are likely to choke off
further development of then new ideas and techniques needed to keep it
working.
so we agreed as a group
to try to provide hardware companies with a way of complying without
harming the community.
My view is mildly more extreme - the 2.4 and 5.8 ghz spectrum currently
allocated to wifi is the *public's* spectrum.
I am deeply concerned about further intrusions on it by things like this:
https://www.qualcomm.com/products/lte/unlicensed
and we need more spectrum, not less, in order to keep wifi for
everyone, working.
I'm looking to find individuals (and other companies!) interested in
working with myself and the foundation, companies, the OpenWrt
community
and eventually regulators to provide guidance to hardware
companies on how to best comply with these rules.
I intend to continue ignoring them to what extent I can. Regrettably
this situation is contributing to community members being unable to
apply new queue management techniques to new standards like 802.11ac,
and seems to be the source of all the proprietary ac firmware.
I think a first step would merely to be for a big maker to publicly
release their 802.11ac firmware and let the chips fall where they may.
If you're interested
in getting involved or just would like to know more, please get in
touch with me. We want to make sure that routers are hackable
and we could use all the help we can get.
+10. I would like to see prpl participating in the make-wifi-fast effort, also.
http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-1265-00-0wng-More-on-Bufferbloat.pdf
Thanks and I look forward to working with you,
Eric
--
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
[email protected]
cell: 920-539-0404
skype: ericschultzwi
@EricPrpl
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Dave Täht
thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
--
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
[email protected]
cell: 920-539-0404
skype: ericschultzwi
@EricPrpl
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
