[Cerowrt-devel] New FCC requirements and CeroWrt

[Cerowrt-devel] New FCC requirements and CeroWrt

[Eric Schultz]

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
so we agreed as a group
to try to provide hardware companies with a way of complying without
harming the community.

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. 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.

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

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

[Dave Taht]

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

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

[Eric Schultz]

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

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

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6749 bytes --]

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

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

[Dave Taht]

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

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

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 9334 bytes --]

On Tue, 9 Dec 2014, Dave Taht wrote:

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

That doesn't surprise me. Radio vendors used similar excuses for charging people 
thousands of dollars for radio programming software and cables. The better ones 
had a jumper (or 0-ohm resister) that could be removed to allow programming.

> 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.

Well, I'll say the same thing here that I've said about wifi and phones on 
airliners. If the system is really that simple to cause crashes with, then why 
are the terrorists planting bombs instead of just shipping a few packages that 
contain phones that turn on during flight and cause the planes to start falling 
out of the sky?

It's just not that hard to build your own equipment to operate on these 
frequencies nowdays. For $200 you can now by a software defined radio board that 
will transmit from 10MHz to 6 GHz, spend a bit of money to build an amplifier 
and you can do FAR more damage to a radar than an access point will.

Also remember, this is weather radar, not the radar that tracks the aircraft.

Also remember that APs operating on these frequencies will be pretty easy to 
track down if they do cause grief. It would be better to have this sort of thing 
taken care of by cracking down on offenders than by trying to police the 
devices.

After all, there's nothing that can prevent someone from buying an AP in europe, 
putting it in their luggage and plugging it in in the US. all the firmware 
lockdown in the world isn't going to prevent this. In fact, making it hard to 
change the country code means that when hardware does move around the world, it 
IS going to be operating on the wrong frequencies, because the user has no way 
to change it.


If you can't tell, this topic and how it's mis-interpreted by so many people, 
some deliberatly, really annoys me. :-)

David Lang

> 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
>
>
>
>

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

[Eric Schultz]

David,

Thanks for the response. We're getting advice from the EFF right now,
and hopefully other groups, on what the requirement is. It's
admittedly vague and hard to separate what the FCC means versus what
developers might think.

You bring up a lot of good points that I need to add to the page to
clarify. I'm not sure in this case you can separate the radio
frequency parameters from the kernel in the case of OpenWrt. I'm not a
kernel engineer but I've tried to general understanding of how the
frequency authorization works in OpenWrt and Linux.

As I understand it, the system for deciding which frequencies to use
is included as part of the kernel in OpenWrt. The kernel uses the
frequency database to decide on what commands to send to the wifi
driver (which include changing frequency, using DFS, etc). The driver
is clearly part of the device at this point. But how should the driver
verify that the commands coming in comply with requirements? It's not
entirely clear. And how does the manufacturer guarantee that only
authorized updates are made to the device?

I want to make clear, the wiki page does not include recommendations.
These were ideas that one of our members were throwing around
internally with their development and legal team. They've asked me to
try to come up with better solutions since they don't really like any
of the ones they've come up with internally.  I'm contacting folks to
try to come up with recommendations for companies so they don't go for
the more extreme routes that unnecessarily lock down devices and hurt
the community.

Eric



On Tue, Dec 9, 2014 at 2: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



-- 
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschultz@prplfoundation.org
cell: 920-539-0404
skype: ericschultzwi
@EricPrpl

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

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 11352 bytes --]


The top of the page says:

his page will compile all relevant information available on the FCC's new 
regulations on 5Ghz Wifi and the OpenWrt's community recommendations for 
hardware manufacturers.

Then down below it lists suggested workarounds. Even though that section says 
they aren't recommendations, it still reads like it.


In Linux/OpenWRT there are several layers to deal with.

The radio itself has it's own processor, which runs some hard-coded software and 
(potentially) some additional firmware that is loaded from the OS (with 
validation and cooperation of the hard-coded software)

The Device Driver talks to the radio processor and can ask it to change channels 
or change country codes (if the radio processor knows about those codes)

The software in the OS asks the device driver to ask the radio to change 
channels.


Manufacturers can put the checking into whatever layer they want. From a 
openwrt point of view, the more that can be changed by openwrt the better.


There is a key word to recognize, the devices need to be "resistant" to 
inappropriate changes. This doesn't mean that they need to be proof against 
them. Based on what happens in other equipment, requiring that the person 
changing this take a clear, unambigous, deliberate action to unlock the radio 
and therefor be clear that they are responsible for anything it does wrong is 
probably good enough. It probably does need to be something other than just a 
software setting though.


What I think would be a good approach is the jumper/0-ohm resister approach 
(google does this with the chrome laptops, open them up, remove a washer that 
acts as a jumper, and it's now unlocked). With the jumper in place, the firmware 
and country code cannot be altered, with it removed, it can be (and a nice big 
warning in the documentation that doing so may be illegal for people to ignore)

It's just not possible to prevent the OS from trying to set the channel 
inappropriately unless you are going to lock down the device to the point that 
you don't allow any software updates at all

David Lang

On Tue, 9 Dec 2014, Eric Schultz wrote:

> Date: Tue, 9 Dec 2014 14:34:14 -0600
> From: Eric Schultz <eschultz@prplfoundation.org>
> To: David Lang <david@lang.hm>
> Cc: Dave Taht <dave.taht@gmail.com>,
>     "cerowrt-devel@lists.bufferbloat.net"
>     <cerowrt-devel@lists.bufferbloat.net>
> Subject: Re: [Cerowrt-devel] New FCC requirements and CeroWrt
> 
> David,
>
> Thanks for the response. We're getting advice from the EFF right now,
> and hopefully other groups, on what the requirement is. It's
> admittedly vague and hard to separate what the FCC means versus what
> developers might think.
>
> You bring up a lot of good points that I need to add to the page to
> clarify. I'm not sure in this case you can separate the radio
> frequency parameters from the kernel in the case of OpenWrt. I'm not a
> kernel engineer but I've tried to general understanding of how the
> frequency authorization works in OpenWrt and Linux.
>
> As I understand it, the system for deciding which frequencies to use
> is included as part of the kernel in OpenWrt. The kernel uses the
> frequency database to decide on what commands to send to the wifi
> driver (which include changing frequency, using DFS, etc). The driver
> is clearly part of the device at this point. But how should the driver
> verify that the commands coming in comply with requirements? It's not
> entirely clear. And how does the manufacturer guarantee that only
> authorized updates are made to the device?
>
> I want to make clear, the wiki page does not include recommendations.
> These were ideas that one of our members were throwing around
> internally with their development and legal team. They've asked me to
> try to come up with better solutions since they don't really like any
> of the ones they've come up with internally.  I'm contacting folks to
> try to come up with recommendations for companies so they don't go for
> the more extreme routes that unnecessarily lock down devices and hurt
> the community.
>
> Eric
>
>
>
> On Tue, Dec 9, 2014 at 2: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
>
>
>
>

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

[Dave Taht]

On Tue, Dec 9, 2014 at 12:34 PM, Eric Schultz
<eschultz@prplfoundation.org> wrote:
> David,
>
> Thanks for the response. We're getting advice from the EFF right now,
> and hopefully other groups, on what the requirement is. It's
> admittedly vague and hard to separate what the FCC means versus what
> developers might think.

The argument that myself, jim gettys, dan geer and bruce schneir have
been making

( https://gettys.wordpress.com/2014/10/06/bufferbloat-and-other-challenges/ )

Is that there is no guarantee that any device will not be hacked, with
or without signing, with or without some lawyers approval, with or
without some arbitrary strings of tests for compliance with existing
regulations.

And, as there is a near certainty of bugs in the default firmware,
there a HUGE need to be able to update firmware in the field, lest we
be spammed to death by our lightbulbs.

I can point to multiple devices that achieved FCC certification that
were very damaging to the airspace, and remain so, with their default
firmware. Take this bug for example...

http://www.bufferbloat.net/issues/216

which cost much hair.

It wouldn't have shown up in any testing regime I know of.

a year later, broadcom found and fixed essentially the same bug. There
are millions of devices in the field that have not been updated, and
will never be updated.

(there are many nuances to these arguments - see geer's talk in
particular, but also jim's comments)

Being "born free", with source code provided to all and the FCC, and
future updates having a *clear* and signed and *public* commit history
is the only means of certainty for ensuring devices actually meet the
spectrum and other requirements, and to continue to do so during the
lifetime of the device.

There is no safety inherent in signed binaries. Buggy code can be signed also.

Any look at a bug database (take cerowrt's closed bugs) will show that
nothing is perfect the first time (remove the open checkbox here)

http://www.bufferbloat.net/projects/cerowrt/issues


There is some safety in signing code that has already been throroughly
vetted at the source and compiler level, and even then, that is hard.

http://cm.bell-labs.com/who/ken/trust.html


>
> You bring up a lot of good points that I need to add to the page to
> clarify. I'm not sure in this case you can separate the radio
> frequency parameters from the kernel in the case of OpenWrt. I'm not a
> kernel engineer but I've tried to general understanding of how the
> frequency authorization works in OpenWrt and Linux.

The process is well documented, and the best that it is possible to do, IMHO.

http://wireless.kernel.org/en/developers/Regulatory

Given evolving regulatory requirements I think this is FAR better than
closed source firmware can do.

> As I understand it, the system for deciding which frequencies to use
> is included as part of the kernel in OpenWrt. The kernel uses the
> frequency database to decide on what commands to send to the wifi
> driver (which include changing frequency, using DFS, etc). The driver
> is clearly part of the device at this point. But how should the driver
> verify that the commands coming in comply with requirements? It's not

The verification step is in the signed database and in a minimal amount
of code that is easily verified. Assurance to the FCC that this code is
in there, and enabled, would be way better than signed binaries or
any other scheme currently on the wiki.

Again, in my case, I am tired of the argument that - in addition to
the firmware on the routers - the onchip firmware must be closed,
because (in addition to many other faults), there is no garuntee that
it will comply either now, or later.

There are zillions of IoT devices that have closed firmware (take
wemo, please), and radios, that have been hacked already.

> entirely clear. And how does the manufacturer guarantee that only
> authorized updates are made to the device?

How does anyone? Given all the exploits published this year, starting
with heartbleed, there *can* be no guarantees.

No lawyer has yet come up with a system of law that can trump natural
law, though they seem to insist on trying.

> I want to make clear, the wiki page does not include recommendations.
> These were ideas that one of our members were throwing around
> internally with their development and legal team. They've asked me to
> try to come up with better solutions since they don't really like any
> of the ones they've come up with internally.  I'm contacting folks to
> try to come up with recommendations for companies so they don't go for
> the more extreme routes that unnecessarily lock down devices and hurt
> the community.

With the exception of the ath9k, they already have.

It is not just bad for the linux community, but for everyone that
shares ALL spectrum,
that radios have all their firmware be locked down.

The genie here is increasingly out of the bottle with software defined
radio also.

>
> Eric
>
>
>
> On Tue, Dec 9, 2014 at 2: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
>
>
>
> --
> Eric Schultz, Community Manager, prpl Foundation
> http://www.prplfoundation.org
> eschultz@prplfoundation.org
> cell: 920-539-0404
> skype: ericschultzwi
> @EricPrpl



-- 
Dave Täht

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