[Battlemesh] Action: fixing *WRT and the FCC
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
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
* *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
* 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.
On Thu, Feb 18, 2016 at 1:54 PM, Michael Richardson <mcr at sandelman.ca>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Battlemesh