[Make-wifi-fast] Firmware patchable WiFi chips for MAC modification

[dpreed at deepplum.com]

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. 

I'm concerned more deeply with bigger technical policy questions where the general benefit to society would be served by using technologies for wireless networking that just don't fit the ancient model of regulation we inherited from old turn of the century thinking, circa Marconi and fixed broadcasting. Adaptive, cooperative sharing using very wideband waveforms are a much better future, but all the captured regulator canaim for is database driven allocation of narrowband channels. Only in Part 15 do we see alternate ideas allowed, and even there, certification is the wrong answer for the future.
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 rethinking above 3 GHz up to 90 GHz, but it isn't happening.

The incumbent licensees see only risks to there business models based on monopoly control. And the tech innovators (e.g the guys who invented 802.11) are not really supported unless some collection of license holders or spectrum 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" <bob.mcmahon at broadcom.com>
Sent: Tue, Mar 20, 2018 at 6:35 pm
To: "dpreed at deepplum.com" <dpreed at deepplum.com>
Cc: "Dave Taht" <dave at taht.net>, "Make-Wifi-fast" <make-wifi-fast at lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] Firmware patchable WiFi chips for MAC modification

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 at deepplum.com 
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 immediate
> 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 firmware
> 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. Under
> 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 not
> 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 Raspberry
> 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 uncertain.
>
>
>
> But I have no idea how to start the conversation with Broadcom.
>
>
>
>
>
>
>
> -----Original Message-----
> From: "Dave Taht" 
> Sent: Friday, March 16, 2018 12:57pm
> To: "dpreed at deepplum.com" 
> Cc: "Make-Wifi-fast" 
> Subject: Re: [Make-wifi-fast] Firmware patchable WiFi chips for MAC
> modification
>
> "dpreed at 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, etc.
> >
> >
> > _______________________________________________
> > Make-wifi-fast mailing list
> > Make-wifi-fast at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>