[Battlemesh] FCC lockdown: closed wifi driver offloaded to a VM

[Daniel Golle]

Hi Ferry,
Hi Benjamin,

On Fri, Jun 10, 2016 at 09:09:15PM +0200, Ferry Huberts wrote:
> I (still) very much feel that people are throwing bigger and bigger measures
> at what essentially is a non-existing problem.
> 
> Really, how many transgressions have there been over the past decade?
> 
> Handing out large fines to people not abiding by the rules should really be
> enough.
> 
> 
> This is getting tiresome....

I'm sick of seeing these severe limitation to the public's (potential)
use of wireless technology being used to show-case arbitary innovations
which just happend to be missing a good marketing strategy (such as
hardware-supported virtualization on very small systems -- not really
such a new thing, after all).
It's predictable that this suggestion is likely to make us end up with
proprietary APIs and drivers lacking everything but the most common
features. Imagine $vendor's blob driver running on their outdated
OpenWrt: In the most lucky case we'll end-up with something like
capwap[1] or even relayd[2]-style. Or their hacked-up versions of
hostapd to get at least the most basic features working.
Short summary: having an additional VM running OpenWrt with a
proprietary WiFi driver is still limiting users much more than just
making sure they stay within the legal boundaries with regard to
transmit power, frequency selection and DFS.
The most clean thing possible (but not implemented by anyone afaik) in
such a world would be somehow tunneling the complete cfg80211-API, and
even then it will most likely lack 'premium' features like Ad-Hoc/IBSS
or even just simple things like better control over and/or feedback
from the rate-control algo.
I see that things will then only work for classical network hierachies
on the lowest level of the pyramid today's networks have become, ie.
I expect AP, AP-WDS and Client-WDS will be well-supported, everything
else has proven to be too obscure for vendors to seriously care about
(and in rare cases catered exclusively to premium customers, not the
general public). Most efforts to improve e.g. mesh networking and all
the tools needed to simulate and experiment with wireless setups would
no longer be applicable under such conditions, see eg. Sven Eckelmann's
recent improvements on mac80211 [3] or improving link metrics such as
in [4]. And of course the opposite to all the work of Dave Tath and the
CeroWrt people which I believe will not be inclined to hear about yet
another few layers of bloat being introduced into every packet's path.


Cheers


Daniel


[1] https://github.com/iosifpeterfi/openCAPWAP-OpenWRT
[2] https://wiki.openwrt.org/doc/recipes/relayclient
[3] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dfdfc2beb0dd7e3a067d2eeacb4623cb48e77658
[4] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cca674d47e59665630f3005291b61bb883015fc5



> 
> 
> On 10/06/16 20:59, Benjamin Henrion wrote:
> > Read this one:
> > 
> > https://hardware.slashdot.org/story/16/06/09/1953201/a-solution-to-the-security-guidelines-proposed-by-fcc-for-home-routers
> > 
> > http://arstechnica.com/information-technology/2016/06/new-router-chips-could-save-open-source-firmware-from-fcc-rules/
> > 
> > It comes down to lock the driver with TPM.
> > 
> 
> -- 
> Ferry Huberts
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh