[Battlemesh] IEEE magazine on FCC lockdown

Wed Apr 20 14:59:01 UTC 2016

Hi William,

thanks for getting back at us!

I didn't receive an e-mail from you (just checked my archives), and my mail 
filters are not very strict ... seems it got lost somewhere.

I'd be gladly available for a (conf) call. Note that we also have the next 
edition of Wireless Battle of the Mesh coming up in 2 weeks in Porto, 
Portugal. We will have a follow up discussion on the FCC topic there [1]. 
Maybe we can patch you in through skype, and please allow me to invite you to 
join us personally, although its rather short notice. ;) We will have ~100 
participants, and I'd assume a majority is pretty interested in the topic.

Also some people have expressed interest in doing a follow up article for 
IEEE, we can try to gather people there to just do that. :)

Thanks,
     Simon

[1] http://battlemesh.org/BattleMeshV9/Agenda#Wednesday_4th_May_2016

On Wednesday 20 April 2016 09:45:56 William wrote:
> Hello Simon et al,
> Interestingly, I sent you an email many months ago asking for a quote for my
> article. It was probably lost in the mix. I would love to print a follow on
> piece. We always look for articles, we are print, therefore it is a nine
> month cycle. Normally, I only get one or two comments from my articles. It
> is kinda of cool to get so much interest. (Typing on my phone)
> I would love a voice chat with you or the group. I can setup a conference
> call.
> 
> Sincerely,
> Will Lumpkins
> Sr. Member IEEE
> IEEE Consumer Electronics Society Magazine Senior Editor
> 972-639-6393
> 
> > On Apr 20, 2016, at 9:36 AM, Simon Wunderlich <sw at simonwunderlich.de>
> > wrote:
> > 
> > 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: 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/e67716bc/attachment.pgp>