From: Dave Taht <dave.taht@gmail.com>
To: make-wifi-fast@lists.bufferbloat.net
Subject: [Make-wifi-fast] Fwd: [Battlemesh] FCC lockdown: closed wifi driver offloaded to a VM
Date: Sun, 12 Jun 2016 09:16:17 -0700 [thread overview]
Message-ID: <CAA93jw7G4+C-vNCioS0V1HSk0KbAv0_EwKYcZE=ELgK4XdehZQ@mail.gmail.com> (raw)
In-Reply-To: <20160612161245.GD1268@makrotopia.org>
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cca674d47e59665630f3005291b61bb883015fc5
looks darn helpful!
---------- Forwarded message ----------
From: Daniel Golle <daniel@makrotopia.org>
Date: Sun, Jun 12, 2016 at 9:12 AM
Subject: Re: [Battlemesh] FCC lockdown: closed wifi driver offloaded to a VM
To: Battle of the Mesh Mailing List <battlemesh@ml.ninux.org>
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@ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
_______________________________________________
Battlemesh mailing list
Battlemesh@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/battlemesh
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
parent reply other threads:[~2016-06-12 16:16 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20160612161245.GD1268@makrotopia.org>]
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='CAA93jw7G4+C-vNCioS0V1HSk0KbAv0_EwKYcZE=ELgK4XdehZQ@mail.gmail.com' \
--to=dave.taht@gmail.com \
--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