From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp70.iad3a.emailsrvr.com (smtp70.iad3a.emailsrvr.com [173.203.187.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1D8563CB5E for ; Wed, 21 Mar 2018 00:38:36 -0400 (EDT) Received: from smtp25.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D0278230FB; Wed, 21 Mar 2018 00:38:35 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp25.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CAE7823991; Wed, 21 Mar 2018 00:38:35 -0400 (EDT) Received: from app44.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B724D230FB; Wed, 21 Mar 2018 00:38:35 -0400 (EDT) X-Sender-Id: MAILER-DAEMON Received: from app44.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Wed, 21 Mar 2018 00:38:35 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app44.wa-webapps.iad3a (Postfix) with ESMTP id A7B1320069; Wed, 21 Mar 2018 00:38:35 -0400 (EDT) Received: by mobile.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Wed, 21 Mar 2018 00:38:35 -0400 (EDT) Date: Wed, 21 Mar 2018 00:38:35 -0400 (EDT) From: "dpreed@deepplum.com" To: "Bob McMahon" Cc: "Dave Taht" , "Make-Wifi-fast" MIME-Version: 1.0 Content-Type: text/plain;charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <1521607115.669910862@mobile.rackspace.com> X-Mailer: mobile/4.1.4 X-Mailman-Approved-At: Wed, 21 Mar 2018 07:49:34 -0400 Subject: Re: [Make-wifi-fast] Firmware patchable WiFi chips for MAC modification 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: Wed, 21 Mar 2018 04:38:36 -0000 Thats useful stuff, Bob. Having participated actively in the FCC Spectrum Policy Task Force and also= serving on the FCC TAC, I know how hard it is to get through that process.= =20 I'm concerned more deeply with bigger technical policy questions where the = general benefit to society would be served by using technologies for wirele= ss networking that just don't fit the ancient model of regulation we inheri= ted from old turn of the century thinking, circa Marconi and fixed broadcas= ting. Adaptive, cooperative sharing using very wideband waveforms are a muc= h better future, but all the captured regulator canaim for is database driv= en allocation of narrowband channels. Only in Part 15 do we see alternate i= deas allowed, and even there, certification is the wrong answer for the fut= ure. The FCC needs a technical vision of a better future. I served on a National= Academies Study that ended up with modest steps, urging regulatory rethink= ing above 3 GHz up to 90 GHz, but it isn't happening. The incumbent licensees see only risks to there business models based on mo= nopoly control. And the tech innovators (e.g the guys who invented 802.11) = are not really supported unless some collection of license holders or spect= rum owners decide to commit. That's why 5G is being defined under the control of cellular operators, and= tuned for their continued dominance. -----Original Message----- From: "Bob McMahon" Sent: Tue, Mar 20, 2018 at 6:35 pm To: "dpreed@deepplum.com" Cc: "Dave Taht" , "Make-Wifi-fast" Subject: Re: [Make-wifi-fast] Firmware patchable WiFi chips for MAC modific= ation FYI, per our regulatory group the FCC KDBs that are relevant. Note: We have provided technical support to help with spectrum policy. It's a long and arduous process. Bob On Fri, Mar 16, 2018 at 12:04 PM, dpreed@deepplum.com=20 wrote: > I agree that it would be nice if broadcom opened its firmware sources. > > > > However, hardware vendors have no incentives to do so, and a number of > disincentives. > > > > In the case of drivers, by opening the API, they get broader support in a > bigger market. > > No such benefit comes from opening the hardware (at least it has not been > shown so far tp be the case). > > > > Worse, FCC and other regulatory regimes base their certification rules on > the idea that purchasers cannot modify or substitute firmware without > recertification. Certification means that the radios operate within Part = 15 > rules at all times. The rules in the U-NII band require pretty serious > restrictions - constant listening for possible Radar signals, and immedia= te > shutdown of channel usage (within 30 sec.) when any radar signal louder > than -62 dBm is sensed on the channel being used. Certifying hardware so = no > possible firmware can disobey those rules is not feasible, so the firmwar= e > must be certified by the vendor. > > > > That said, I am a licensed Amateur Radio operator. In much of the WiFi > bands I can operate radios under Part 97, rather than Part 15, rules. Und= er > Part 97, I have the ability to "self-certify" any hardware at all, > including any modifications of firmware or hardware, as long as I operate > the radios within Part 97 rules, which require that I be fully aware and > responsible for the transmissions' waveforms and content, at the > engineering level. > > > > So it would be great if Broadcom would publish the specs for use by > licensed Amateurs alone. Manufacturers can sell radio components to hams > without certifications of any kind. > > > > I doubt the Amateur market is of interest to Broadcom at this point. The > market size is trivial compared to their main market. Most Amateurs are n= ot > interested in operation at frequencies above 1 GHz, though there are some > experimentalists who are. Most Amateurs are also not interested in > high-bit-rate digital operation either. I find that sad, and wish it were > not the case. > > > > However, Eben Upton's success in turning an obsolescent CPU chip into a > worldwide phenomenon (Raspberry Pi) gives me hope. Note that the Raspberr= y > Pi also contains undocumented/secret hardware that required > reverse-engineering, and the chip also comes from Broadcom. > > > > So effort spent on Broadcom to open things at the radio firmware level up > would be worthwhile, I think. Far easier than Atheros/Qualcomm, which is > now being pitched to the highest bidder and whose future is very uncertai= n. > > > > But I have no idea how to start the conversation with Broadcom. > > > > > > > > -----Original Message----- > From: "Dave Taht"=20 > Sent: Friday, March 16, 2018 12:57pm > To: "dpreed@deepplum.com"=20 > Cc: "Make-Wifi-fast"=20 > Subject: Re: [Make-wifi-fast] Firmware patchable WiFi chips for MAC > modification > > "dpreed@deepplum.com" writes: > > > https://github.com/seemoo-lab/nexmon > > > > Looks like a very useful toolkit for experimentation in making wifi > fast. I'm > > guessing that the queues can be managed better, for example. > > Lot a dissassembly required. > > > > > Notice at least one Lede router works, along with Raspberry Pi 3, etc. > > The rpi3 is a good target. Still, it would be better to convince > broadcom to make sources available to some developers. > > > > > Also, ability to transmit arbitary waveform from quadrature samples > using DAC. > > https://github.com/seemoo-lab/mobisys2018_nexmon_software_defined_radio > > > > The reception via ADC of a sampled waveform seems to be undemonstrated, > but may > > be feasible. If so, one can experiment with alternative modulations, et= c. > > > > > > _______________________________________________ > > Make-wifi-fast mailing list > > Make-wifi-fast@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/make-wifi-fast > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast >