[Battlemesh] IEEE magazine on FCC lockdown

Simon Wunderlich sw at simonwunderlich.de
Wed Apr 20 15:44:27 UTC 2016


Hi Jonathan,

On Wednesday 20 April 2016 18:13:04 Jonathan Morton wrote:
> > On 20 Apr, 2016, at 17:36, Simon Wunderlich <sw at simonwunderlich.de> wrote:
> > 
> > Personally, I wouldn't mind a firmware which just locks the radio stuff
> > (and ONLY the radio) so we can get some peace in this discussion. But
> > from the past experience, vendors tend to put all kind of things into the
> > firmware instead of making it small.
> 
> I’ve said this before: we need a clean separation of Layer 1 and Layer 2 in
> wifi.
> 
> Layer 1, as everyone here *should* know, is the physical layer.  I place the
> radio itself here, and in modern wifi chipsets that’s a software-defined
> radio.  There are some gnarly DSP routines involved here, and I imagine
> vendors consider those to be sensitive IP.  But that’s fine - once they’re
> working right, we don’t need to touch them again.  Bundle it in a
> crypto-signed package with a regulatory database, burn it (or the
> verification key) into the chipset and lock it down hard.
> 
> Job done, the FCC et al should be satisfied; the only people who lose out
> are the amateur-band folks who want to go beyond the licence-free
> frequencies.
> 
> Layer 2 is the MAC - media-access controller.  This is where rate selection,
> negotiation for airtime, framing, aggregation, retries, etc happen.  It’s
> entirely possible to leave much of this up to the host CPU, with just a few
> specialised buffers and helper functions implemented on the wifi chipset. 
> It’s also entirely possible to do it all on the chipset, relieving the host
> of some timing constraints but reducing flexibility for experimentation.
> 
> But the MAC functions have nothing to do with the frequency-power emissions
> of the radio, from a regulatory standpoint.  We need to be able to change
> the MAC to make wifi better.  With separated layers 1 & 2, we can do that
> without having to re-certify the radio.

Unfortunately, I don't think a clean separation is possible because of DFS, 
which exactly brought into this mess.

For DFS, we need to detect radars (that's layer 1). But once it was detected, 
we need to send a channel switch announcement (layer 2) and make stations or 
other mesh participants move to a new channel together with us.

That's exactly the part which wasn't implemented or disabled in the drivers 
(by users, firmwares, etc), which brought up this problem.

Cheers,
     Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20160420/2730d639/attachment.pgp>


More information about the Battlemesh mailing list