From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp110.iad3a.emailsrvr.com (smtp110.iad3a.emailsrvr.com [173.203.187.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A80CF3B2AE for ; Mon, 14 Mar 2016 13:49:01 -0400 (EDT) Received: from smtp6.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1EC5F1804C3; Mon, 14 Mar 2016 13:49:01 -0400 (EDT) Received: from app19.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0899D18048E; Mon, 14 Mar 2016 13:49:00 -0400 (EDT) X-Sender-Id: dpreed@reed.com Received: from app19.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 13:49:01 -0400 Received: from reed.com (localhost [127.0.0.1]) by app19.wa-webapps.iad3a (Postfix) with ESMTP id E5BAC6125E; Mon, 14 Mar 2016 13:49:00 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Mon, 14 Mar 2016 13:49:00 -0400 (EDT) Date: Mon, 14 Mar 2016 13:49:00 -0400 (EDT) From: dpreed@reed.com To: "Wayne Workman" Cc: "Jonathan Morton" , "bufferbloat-fcc-discuss" , make-wifi-fast@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: <1457964158.79616218@mobile.rackspace.com> <7E8F9D99-38F8-47CD-960E-45100844B161@gmail.com> X-Auth-ID: dpreed@reed.com Message-ID: <1457977740.938414893@apps.rackspace.com> X-Mailer: webmail/12.2.3-RC Subject: Re: [Make-wifi-fast] [bufferbloat-fcc-discuss] [Cerowrt-devel] arstechnica confirmstp-link router lockdown X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 17:49:01 -0000 Well, the answer is basically no on there being a current chip that is only= concerned with the PHY layer. Because chip count is a crucial part of syst= em cost, years ago it became the practice to put the PHY and MAC, and now t= he protocol processing too, on the same mixed-signal chip. For example the = ESP8266 (the IoT favorite WiFi maker gadget) has a 32 bit general purpose p= rocessor and all of the elements of basic MAC and PHY on the chip. You can = program the ESP8266 and use its WiFi just fine.=0A=0ABut I would argue that= it is no longer true that division by a hardware interface routed through = the PC board need be the solution. Modularity on board the chip (as in the= ESP8266) is sufficient to do what I described - the PHY layer can isolated= (even if it is implemented in updatable firmware) if the firmware that con= trols the transmission DAC is isolated, locked down, and enforces the band = limit and power limit required by the FCC. It can even be updatable, as lon= g as it is protected with an adequate barrier to consumer modification. It = need not be secret - in fact it would be better if it could be reviewed by = those concerned with ensuring it will actually limit the output.=0A=0ANow i= n other radios, less integrated, there are separate chips for the transmit = DAC path from the protocol path. I use those chips in my experimental Part= 97 transceivers on 2.4 and 5 GHz, and there are chips from MAXIM and Analo= g Devices for example, that might be appropriate if you want to design your= own router, however they are never going to be part of consumer devices be= cause using them is costly. If you want to enforce a filter, you can do tha= t fairly easily. But to implement full 802.11ac OFDM + MIMO would be a bear= of a DSP program to build from scratch for these chips, though in principl= e they are capable of doing that.=0A=0ABut in the fully integrated designs,= there is enough modularity *on-chip* that one could make sure that there a= re no signals emitted that are outside the relevant band and power limits. = (one might even just do this by detecting that limits are exceeded and pow= ering of the transmit amplifier, which would probably make the FCC even mor= e happy... the algorithm to detect excess power or out-of-band emissions co= uld be quite simple, compared to a filter spliced in the signal path).=0A= =0AAn external "limit-exceeding signal detector" could also be very inexpen= sive, if it did not need to do ADC from the transmitted signal, but could g= et access to the digital samples and do a simple power measurement.=0A=0A= =0A=0A=0A=0A=0AOn Monday, March 14, 2016 12:16pm, "Wayne Workman" said:=0A=0A> Is there an existing chip that is only co= ncerned with layer 1?=0A> On Mar 14, 2016 9:15 AM, "Jonathan Morton" wrote:=0A> =0A>>=0A>> > On 14 Mar, 2016, at 16:02, dpreed= @reed.com wrote:=0A>> >=0A>> > The WiFi protocols themselves are not a worr= y of the FCC at all.=0A>> Modifying them in software is ok. Just the physic= al emissions spectrum must=0A>> be certified not to be exceeded.=0A>> >=0A>= > > So as a practical matter, one could even satisfy this rule with an=0A>>= external filter and power limiter alone, except in part of the 5 GHz band= =0A>> where radios must turn off if a radar is detected by a specified algo= rithm.=0A>> >=0A>> > That means that the radio software itself could be tas= ked with a=0A>> software filter in the D/A converter that is burned into th= e chip, and not=0A>> bypassable. If the update path requires a key that is = secret, that should=0A>> be enough, as key based updating is fine for all r= adios sold for other uses=0A>> that use digital modulation using DSP.=0A>> = >=0A>> > So the problem is that 802.11 chips don't split out the two functi= ons,=0A>> making one hard to update.=0A>>=0A>> To put this another way, wha= t we need is a cleaner separation of ISO=0A>> Layers 1 (physical) and 2 (MA= C).=0A>>=0A>> The FCC is concerned about locking down Layer 1 for RF compli= ance. We=E2=80=99re=0A>> concerned with keeping Layer 2 (and upwards) open= for experimentation and=0A>> improvement.=0A>>=0A>> These are compatible g= oals, at the fundamental level, but there is a=0A>> practical problem with = existing implementations which mix the layers=0A>> inappropriately.=0A>>=0A= >> - Jonathan Morton=0A>>=0A>> ___________________________________________= ____=0A>> bufferbloat-fcc-discuss mailing list=0A>> bufferbloat-fcc-discuss= @lists.redbarn.org=0A>> http://lists.redbarn.org/mailman/listinfo/bufferblo= at-fcc-discuss=0A>>=0A> =0A