[Battlemesh] IEEE magazine on FCC lockdown

[Simon Wunderlich]

Hi Leonardo,

On Wednesday 20 April 2016 16:01:43 leonardo wrote:
> [...]
> > And his statement "FCC is calling out in FCC 14-30 is the “firmware”
> > that is
> > located inside the radio chip or application-specific integrated
> > circuit" is
> > rather controversial because they used the term "DD-WRT" (which is a
> > device
> > firmware and not a wifi chip firmware) earlier in their
> > questionnaire. It was
> > most likely not their intent but they made it really hard not to
> > interpret it
> > this way. And right now, WiFi firmware chip versions can still be
> > replaced and
> > mostly only hindered the lawful use of the devices (e.g. in mesh
> > networks with
> > ath10k). I don't know (but could easily be wrong) of any widely
> > deployed wifi
> > chip used in community networks which uses some kind of cryptographic
> > mechanism which would stop anyone from installing a hacked wifi chip
> > firmware
> > (and wifi chip firmware only). But even when it doesn't exist now -
> > maybe this
> > will come and thus confirm his standpoint.
> 
> This is the point that i wanted to discuss. There is this line of
> interpretation that says "intentions of FCC are good, implementation is
> wrong". Where:
>  - intentions means: "lock down frequency/powerlevel/DFS..." in the
> Radio chip to use the unlicensed spectrum as FCC mandates.
>  - implementations is what Simon said in the other email: since vendors
> like tp-link today can not simply enforce the lockdown on the radio
> -only, they locked everything to stay on the market.
> 
> Now let's say that tomorrow technology X allows to lock down radio
> firmware. Do we like it or not? would this be a reasonable trade-off to
> preserve our ability to reflash the OS in the device? in the
>  bufferbloat-FCC-discuss ML it seems the answer is a big NO, I'd like
> to know how this ML feels.

We haven't seen this yet, so this is a more a theoretical question. 
Practically, what we see today e.g. in ath10k is a big firmware which has all 
sorts of limitations (no ad-hoc support, limited amount of peers, closed 
source).

Also, these firmwares are actually uploaded from the host (i.e. the router 
firmware), and therefore can easily be replaced.

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.

> Concretely, since in Europe we have the ongoing similar problem, should
> we go to our governments and convince them that they should apply a
> "lock the radio" implementation of the Radio Directive?

No, because vendors will not practically implement that - at least as far as I 
see. And if they don't implement minimal firmware with locking, we are back to 
the previous problem and AP vendors will just default to lock the whole 
firmware.

> 
> > We will not start to being happy and praise the new FCC requirements
> > but I
> > think he has the rights to point out the intentions we may (or may
> > not) have
> > missed. But at least for me it was nothing new which wasn't written
> > already at
> > many other articles.
> 
> We also have the rights to tell IEEE Consumer Electronics Magazine our
> opinion, if we want. We can ask the editors (among them there is also
> the author of the piece) if they are interested in a 2-pages paper
> stating the point of view of the community.

Sure, if you want to work on that, feel free to do so. :)

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