<div dir="ltr"><div>I&#39;d like to propose a plan of action. </div><div><br></div><div>How can it be improved? Dave, is it realistic?</div><div><br></div><div>1. Develop TDWR interference mitigation (&lt;2 hours initial dev time)</div><div>2. Work with FCC saying &quot;we have developed a fix for current devices&quot;</div><div>3. Apply TDWR fix to *WRT mainline</div><div>4. Work with FAA/FCC to expand hardware coverage of fix (aka encourage openness)</div><div><br></div><div>Here are a few reasons the FCC may care:</div><div> - Currently interfering devices can be fixed</div><div> - *Future* issues may be fixed via cooperation with the FCC</div><div> - FCC is seen as progressive, responsive to public needs</div><div> - Better for FCC, manufacturers, developers and consumers in security, costs and features<br></div><div><div><br></div></div><div>The agreement:</div><div>* *WRT promises that their source and builds will have TDWR interference mitigation enabled by default</div><div>* *WRT promises to vet manufacturer forks of *WRT, verifying that the TDWR mitigation is not disabled</div><div>* FCC will work with *WRT in improving TDWR interference mitigation for all devices</div><div>* FCC simplifies certification if the device is running *WRT</div><div><br></div><div>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.</div><div><br></div><div>I suggest that *WRT implement a software solution that supplements DFS.</div><div><br></div><div>How might the conditions be detected and mitigated?</div><div> - Default to TDWR interference mitigation (aka avoid specific channels) unless the following are *not* an issue</div><div> - Record the temperature of the device and compare it to expected weather</div><div> - Geolocation vs. database of the 45 airport locations</div><div> - WiFi-based location check (a la google) vs. database</div><div> - During setup, ask users if installation is outdoors<br></div><div> - Bypass heuristic if DFS is known to work with device (via FCC testing)</div><div> - Some combination of the above</div><div><br></div><div>It&#39;s important for a user to understand - none of this means your device will have poor performance.</div><div><br></div><div>Crucially, rev1 (just disable specific channels) is dead simple and an immediate improvement for the FAA/FCC.</div><div><br></div><div>To the FCC: &quot;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.&quot; and go from there.</div><div><br></div><div>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.</div><div><br></div><div class="gmail_extra"><div><div><div dir="ltr"><div>David<br></div></div></div></div>
<br><div class="gmail_quote">On Thu, Feb 18, 2016 at 1:54 PM, Michael Richardson <span dir="ltr">&lt;<a href="mailto:mcr@sandelman.ca" target="_blank">mcr@sandelman.ca</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>Simon Kelley &lt;<a href="mailto:simon@thekelleys.org.uk" target="_blank">simon@thekelleys.org.uk</a>&gt; wrote:<br>
    &gt; I&#39;ve just ordered one of these to replace a TP-link MR3020<br>
<br>
    &gt; <a href="http://www.gl-inet.com/ar150/" rel="noreferrer" target="_blank">http://www.gl-inet.com/ar150/</a><br>
<br>
    &gt; they come with manufacturer support for OpenWRT, though this one is<br>
    &gt; a new model which doesn&#39;t yet have stable-build support. The<br>
    &gt; previous version is still available and does.<br>
<br>
</span>It&#39;s a nice stop-gap.<br>
What kind of radio does it have, I assume broadcom?<br>
I don&#39;t see how it will help with the FTTN/FTTH situation though.<br>
<span><br>
--<br>
]               Never tell me the odds!                 | ipv6 mesh networks [<br>
]   Michael Richardson, Sandelman Software Works        | network architect  [<br>
]     <a href="mailto:mcr@sandelman.ca" target="_blank">mcr@sandelman.ca</a>  <a href="http://www.sandelman.ca/" rel="noreferrer" target="_blank">http://www.sandelman.ca/</a>        |   ruby on rails    [<br>
<br>
</span><div><div>_______________________________________________<br>
bufferbloat-fcc-discuss mailing list<br>
<a href="mailto:bufferbloat-fcc-discuss@lists.redbarn.org" target="_blank">bufferbloat-fcc-discuss@lists.redbarn.org</a><br>
<a href="http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss" rel="noreferrer" target="_blank">http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss</a><br>
</div></div></blockquote></div><br></div></div>