From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B432321F31B for ; Tue, 9 Dec 2014 12:32:22 -0800 (PST) Received: by mail-oi0-f51.google.com with SMTP id e131so978026oig.38 for ; Tue, 09 Dec 2014 12:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CMqDJCGmUs7/ZncGOneC25a65tKOlyZRs4CPVLD0vjM=; b=h0BRdZ1acKIK0PKiSA4gkcrpuCkkAjtE0PUKfRXWmSJ+dqASWZ5m3otLixmfNiD5fZ DoWQZTXaRvLmDWR0rCXNgBuXptLGcrL6vsKwrK4FHT+Pdr8q3nfzeTdmCnMmzhzuFw8h DaaA2Tez1M6977e/6+xban20TDKmvEWAbhSVbEWOD1r8IEFuZaWcl8elqgXrP5AX+953 QWKxya94iZYBTc9Gs4PePRObpFBWBmp1SQbZ9BXjqHT4nmZawxp54L+hW6m+CTW0UDv+ 0kVuJcxQUlyMzxOEuDkhEbPUavdwYYBpy86DtT3YqB5aaOY3hmoKKEqJgfnOYYdQ5Md2 zxVg== MIME-Version: 1.0 X-Received: by 10.182.165.69 with SMTP id yw5mr256331obb.36.1418157141342; Tue, 09 Dec 2014 12:32:21 -0800 (PST) Received: by 10.202.227.77 with HTTP; Tue, 9 Dec 2014 12:32:21 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Dec 2014 12:32:21 -0800 Message-ID: From: Dave Taht To: David Lang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Eric Schultz , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] New FCC requirements and CeroWrt X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 20:32:51 -0000 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 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 th= at > 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 softwar= e > implementing the 802.11(whatever) protocol on that RF portion must be loc= ked > 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 wik= i > 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 descriptio= n 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 abou= t > the radio, not the entire computer that has a radio as part of it. > > According to the background, they are worried about interference with rad= ar, > 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 th= at > 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 wrote: >>> >>> On Tue, Dec 9, 2014 at 9:11 AM, Eric Schultz >>> 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_w= ifi) >>>> 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 effor= t, >>> 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=C3=A4ht >>> >>> 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 --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks