[Cerowrt-devel] New FCC requirements and CeroWrt
dave.taht at gmail.com
Tue Dec 9 15:32:21 EST 2014
Well, I have heard this regulation as yet another excuse from several
vendors for not opening their firmware.
I DO care a lot about planes not crashing due to someone streaming
netflix in the flight path.
On Tue, Dec 9, 2014 at 12:14 PM, David Lang <david at lang.hm> wrote:
> 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
> 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
>> 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
> David Lang
> On Tue, 9 Dec 2014, Eric Schultz wrote:
>> 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
>> 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,
>> On Tue, Dec 9, 2014 at 11:49 AM, Dave Taht <dave.taht at gmail.com> wrote:
>>> On Tue, Dec 9, 2014 at 9:11 AM, Eric Schultz
>>> <eschultz at prplfoundation.org> wrote:
>>>> 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
>>>> 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
>>>> 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
>>> 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
>>>> 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,
>>>> Thanks and I look forward to working with you,
>>>> Eric Schultz, Community Manager, prpl Foundation
>>>> eschultz at prplfoundation.org
>>>> cell: 920-539-0404
>>>> skype: ericschultzwi
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel at lists.bufferbloat.net
>>> Dave Täht
>> Eric Schultz, Community Manager, prpl Foundation
>> eschultz at prplfoundation.org
>> cell: 920-539-0404
>> skype: ericschultzwi
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
More information about the Cerowrt-devel