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 <[email protected]> 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 <[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 -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
