Lets make wifi fast again!
 help / color / mirror / Atom feed
From: "dpreed@deepplum.com" <dpreed@deepplum.com>
To: "Dave Taht" <dave@taht.net>
Cc: "Make-Wifi-fast" <make-wifi-fast@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] Firmware patchable WiFi chips for MAC modification
Date: Fri, 16 Mar 2018 15:04:12 -0400 (EDT)	[thread overview]
Message-ID: <1521227052.27412047@apps.rackspace.com> (raw)
In-Reply-To: <874llgj6v1.fsf@nemesis.taht.net>

[-- Attachment #1: Type: text/plain, Size: 3861 bytes --]


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" <dave@taht.net>
Sent: Friday, March 16, 2018 12:57pm
To: "dpreed@deepplum.com" <dpreed@deepplum.com>
Cc: "Make-Wifi-fast" <make-wifi-fast@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] Firmware patchable WiFi chips for MAC modification



"dpreed@deepplum.com" <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, etc.
>
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

[-- Attachment #2: Type: text/html, Size: 6653 bytes --]

  reply	other threads:[~2018-03-16 19:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15 19:41 dpreed
2018-03-16 16:57 ` Dave Taht
2018-03-16 19:04   ` dpreed [this message]
2018-03-20 22:35     ` Bob McMahon
2018-03-21  4:38 dpreed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1521227052.27412047@apps.rackspace.com \
    --to=dpreed@deepplum.com \
    --cc=dave@taht.net \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox