From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 385433B2B5 for ; Mon, 14 Mar 2016 10:02:39 -0400 (EDT) Received: from smtp14.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EF33D2807FE; Mon, 14 Mar 2016 10:02:38 -0400 (EDT) Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DEAF82807BA; Mon, 14 Mar 2016 10:02:38 -0400 (EDT) X-Sender-Id: MAILER-DAEMON Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.5.4); Mon, 14 Mar 2016 10:02:38 -0400 Received: from reed.com (localhost [127.0.0.1]) by app15.wa-webapps.iad3a (Postfix) with ESMTP id C5F29C0089; Mon, 14 Mar 2016 10:02:38 -0400 (EDT) Received: by mobile.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Mon, 14 Mar 2016 10:02:38 -0400 (EDT) Date: Mon, 14 Mar 2016 10:02:38 -0400 (EDT) From: dpreed@reed.com To: "David Lang" Cc: make-wifi-fast@lists.bufferbloat.net, "bufferbloat-fcc-discuss" , cerowrt-devel@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: text/plain;charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <1457964158.79616218@mobile.rackspace.com> X-Mailer: mobile/4.0.0 Subject: Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirmstp-link router lockdown X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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: Mon, 14 Mar 2016 14:02:39 -0000 As a software guy who can solder SMT chips and design PCBs, and a licensed = amateur radio operator, let me add a couple observations. The FCCs concern is not to lock up all software on routers. All they call = for is that at certification time and in users hands, radio emissions are r= estricted to the rules of Part 15 operation. So one can manufacture a router that can be certified, but with the ability= to operate outside the legal 2.4 GHz channel and 5 GHz channels, and power= limits and that quirky radar protection rule locked in via some difficult = to break lock. It needn't be a perfect lock... If it requires the ability t= o solder or unsolder SMT chips, or spending $1000 for parts and services pe= r device, that could satisfy. After all, just R-SMA connectors were suffici= ent for antenna mod prevention to be certified. The WiFi protocols themselves are not a worry of the FCC at all. Modifying = them in software is ok. Just the physical emissions spectrum must be certif= ied not to be exceeded. So as a practical matter, one could even satisfy this rule with an external= filter and power limiter alone, except in part of the 5 GHz band where rad= ios must turn off if a radar is detected by a specified algorithm. That means that the radio software itself could be tasked with a software f= ilter in the D/A converter that is burned into the chip, and not bypassable= . If the update path requires a key that is secret, that should be enough, = as key based updating is fine for all radios sold for other uses that use d= igital modulation using DSP. So the problem is that 802.11 chips don't split out the two functions, maki= ng one hard to update. Router vendors should like having this feature, in the standard chipsets, a= ctually. Why? Because it makes their own products easier to certify, the sa= me way a secure microkernel makes security properties easier to certify, in= , say, L4. And because the rules about channels and power are different in = each national market. Who wants to submit all their source code to each cou= ntry's regulator? So I personally would be frustrated that I would not be able to mod any rou= ter to operate under Ham rules(part 97 allows hams to operate in much of, b= ut not all of, the two 802.11 bands with equipment we can make modify and o= perate with only self-certification, and the operator following Amateur ope= rating rules, which are different, but allow 802.11 outside the unlicensed = bands also, at higher power, too). But that matters less, because I can sol= der and validate my transmitters. Perhaps there is common ground to be found. Dave Taht and I made the first = move on this, with Dave's DC meeting with the FCC. But it will take working with both the FCC and the chip vendors, and the ho= me access point vendors with a common purpose and agenda. That agenda needs= to be to find the minimum lock that will satisfy the FCC, and a sufficient= ly cheap implementation that, along with the cost saving on design certific= ation, it is cheaper to make a router that is otherwise open, than to make = one whose certification depends on review of all the code in the router. This is a common design pattern. The DAA for phones is now purchasable as a= single module, FCC precertified, so one can make any kind of cordless phon= e be certifiable, merely by using that part. That part is more expensive th= an one I could design myself, but it saves on certification cost, because t= he rest of the phone or modem doesnt need certification, so one can innovat= e. Hope this helps. Happy to advise, and also help get the FCC on board when t= here is a need to. Before that, I'd suggest convo with Atheros, Broadcom, M= arvell, etc. Or even Intel, which may want it for its WiFi embedded busines= ses.