Re: [Cerowrt-devel] New FCC requirements and CeroWrt

[Dave Taht <dave.taht@gmail.com>]

Well, I have heard this regulation as yet another excuse from several
vendors for not opening their firmware.

http://wiki.prplfoundation.org/wiki/Complying_with_FCC_rules_on_5ghz_wifi

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@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
> 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 <dave.taht@gmail.com> wrote:
>>>
>>> On Tue, Dec 9, 2014 at 9:11 AM, Eric Schultz
>>> <eschultz@prplfoundation.org> 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
>>>> eschultz@prplfoundation.org
>>>> cell: 920-539-0404
>>>> skype: ericschultzwi
>>>> @EricPrpl
>>>> _______________________________________________
>>>> Cerowrt-devel mailing list
>>>> Cerowrt-devel@lists.bufferbloat.net
>>>> 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
>> eschultz@prplfoundation.org
>> cell: 920-539-0404
>> skype: ericschultzwi
>> @EricPrpl
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks