[Battlemesh] Action: fixing *WRT and the FCC

David Hilton quercus.aeternam at gmail.com
Thu Feb 18 20:34:30 UTC 2016


I'd like to propose a plan of action.

How can it be improved? Dave, is it realistic?

1. Develop TDWR interference mitigation (<2 hours initial dev time)
2. Work with FCC saying "we have developed a fix for current devices"
3. Apply TDWR fix to *WRT mainline
4. Work with FAA/FCC to expand hardware coverage of fix (aka encourage
openness)

Here are a few reasons the FCC may care:
 - Currently interfering devices can be fixed
 - *Future* issues may be fixed via cooperation with the FCC
 - FCC is seen as progressive, responsive to public needs
 - Better for FCC, manufacturers, developers and consumers in security,
costs and features

The agreement:
* *WRT promises that their source and builds will have TDWR interference
mitigation enabled by default
* *WRT promises to vet manufacturer forks of *WRT, verifying that the TDWR
mitigation is not disabled
* FCC will work with *WRT in improving TDWR interference mitigation for all
devices
* FCC simplifies certification if the device is running *WRT

Currently, the only interference mitigation is DFS. The FAA/FCC have
problems with highly placed, outdoor devices near airports, but these
devices may not have (working) DFS.

I suggest that *WRT implement a software solution that supplements DFS.

How might the conditions be detected and mitigated?
 - Default to TDWR interference mitigation (aka avoid specific channels)
unless the following are *not* an issue
 - Record the temperature of the device and compare it to expected weather
 - Geolocation vs. database of the 45 airport locations
 - WiFi-based location check (a la google) vs. database
 - During setup, ask users if installation is outdoors
 - Bypass heuristic if DFS is known to work with device (via FCC testing)
 - Some combination of the above

It's important for a user to understand - none of this means your device
will have poor performance.

Crucially, rev1 (just disable specific channels) is dead simple and an
immediate improvement for the FAA/FCC.

To the FCC: "We have a software solution that works for all linux-based
devices. We would like to help solve this problem for all existing devices,
not just new devices." and go from there.

Manufacturers may opt to *add* our fix to their code, or may choose to open
the source and allow *WRT* to add compatibility with their device.

David

On Thu, Feb 18, 2016 at 1:54 PM, Michael Richardson <mcr at sandelman.ca>
wrote:

> Simon Kelley <simon at thekelleys.org.uk> wrote:
>     > I've just ordered one of these to replace a TP-link MR3020
>
>     > http://www.gl-inet.com/ar150/
>
>     > they come with manufacturer support for OpenWRT, though this one is
>     > a new model which doesn't yet have stable-build support. The
>     > previous version is still available and does.
>
> It's a nice stop-gap.
> What kind of radio does it have, I assume broadcom?
> I don't see how it will help with the FTTN/FTTH situation though.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
>
> _______________________________________________
> bufferbloat-fcc-discuss mailing list
> bufferbloat-fcc-discuss at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20160218/9626b2ed/attachment-0001.htm>


More information about the Battlemesh mailing list