<div dir="ltr">Indeed, using a tool that switches a node's radio over to monitor mode would yield lots of info about free or occupied channels, although this would have to be 'out of band' since it effectively disables the AP. I was curious more about doing periodic noise surveys using both the 'iw wlan0 survey dump' tool, in conjunction with the link ETX values reported by olsrd, so as to not disable the AP.<br>
<br>The survey dump could at least help identify those neighbor's APs which are particularly strong (i.e. sources of interference). The link ETX values, along with the signal dB values vs. TX retry amounts reported by iw wlan0 station dump, would give some measure of the current channel's quality.<br>
<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 20, 2014 at 8:43 AM, Grady Johnson <span dir="ltr"><<a href="mailto:grady@opentechinstitute.org" target="_blank">grady@opentechinstitute.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
I had some thoughts a while back about using nodes for spectrum<br>
sensing and came across LinSSID, a Linux-based spectrum analyzer:<br>
<a href="http://sourceforge.net/projects/linssid/" target="_blank">http://sourceforge.net/projects/linssid/</a><br>
<br>
It uses the Linux Wi-Fi drivers to dynamically sense the spectrum<br>
environment across compatible channels. It's probably too resource<br>
intense to run on the average node, but could be used on higher<br>
resource backbone nodes (or client devices) and could feed the data<br>
into a central server.<br>
<br>
Obviously, this would largely tie up the node's radio while it was<br>
sampling the spectrum, but it wouldn't have to do it continuously,<br>
only say every hour or even once a day.<br>
<div class=""><br>
On 05/19/2014 05:23 PM, Ben West wrote:<br>
> Simon Wunderlich gave a talk at this year's Battlemesh about<br>
> progress in implementing DFS (dynamic frequency selection) in mesh<br>
> networks, whether through user-space tools or in kernel space.<br>
><br>
> <a href="http://www.battlemesh.org/BattleMeshV7/Agenda?action=AttachFile&do=view&target=2014-05-17_wbmv7_DFS.pdf" target="_blank">http://www.battlemesh.org/BattleMeshV7/Agenda?action=AttachFile&do=view&target=2014-05-17_wbmv7_DFS.pdf</a><br>
><br>
> The intended application from Simon's perspective is to permit<br>
> automated channel hopping for meshes, as required for operating on<br>
> those 5.8GHz bands shared with radar installations. Although his<br>
> talk focused on the EU regulatory environment, the incentives for<br>
> using these channel in the US would be similar (avoiding otherwise<br>
> crowded channels).<br>
><br>
> My understanding is that the FCC presently requires unlicensed<br>
> 5.8GHz radios operating on these channels to be be able to sense<br>
> the present of radar and hop to another channel, and Ubiquiti stock<br>
> firmware for their AirMAX products (e.g. Nanostation M5) now does<br>
> this. W/r/t running adhoc networks on DFS channels, I'm not sure<br>
> if the FCC explicitly forbids beaconing, or if radios may sample<br>
> the band for 30secs before sending out beacons. The FCC regs may<br>
> be vague on this detail right now.<br>
><br>
> I'm pointing out this particular talk, however, because the ability<br>
</div>> for a mesh to reliably channel-hop would also be *very useful* for<br>
<div class="">> 2.4GHz meshes. That band now sees potentially destructive noise<br>
> from channel-hopping neighbors, i.e. one day your mesh works, the<br>
> next day it doesn't. Manually keeping up where a clear channel<br>
> happens to be becomes increasingly untenable.<br>
><br>
> Any high-level thoughts about mesh-wide noise sensing and channel<br>
> hopping schemes for a platform like Commotion?<br>
><br>
><br>
><br>
</div>> _______________________________________________ Commotion-discuss<br>
> mailing list <a href="mailto:Commotion-discuss@lists.chambana.net">Commotion-discuss@lists.chambana.net</a><br>
> <a href="https://lists.chambana.net/mailman/listinfo/commotion-discuss" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-discuss</a><br>
><br>
<br>
- --<br>
Grady Johnson<br>
Open Technology Institute | New America Foundation<br>
@geekwrights<br>
D6AE 65CE 141B 8DBC 7B5F 99AA 6BCC 0833 8B28 833B<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.14 (GNU/Linux)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iQEcBAEBAgAGBQJTe1v/AAoJEGvMCDOLKIM7lZ8H/if7cVFYO7wkRczQZDWIKUCD<br>
18GyrwNuN4kgjkPrZLi4SIDJnB1AtL/Caw4CG9ojw4q4AxCB4mc3KISiHbAsw3ft<br>
wljxjMhdrzEJ8d+mNFRD3pmDQuVY9/3LGTyj5kX+X6hE5/PDcau5LkzX2/xQfjbW<br>
t1YYjjWNTzwR1UPJmH0AJkWGjZdQADjMepcbgUE31ul3IMvB0rLr1QrZUdlJIt7V<br>
1p1LSHAYnzqtNQAbYBYi3h6Oyw0LSDVK/kuhKm4iBIcxOCq4KBcyk9s9uSu3kWAH<br>
u3hcmYcgUZDJMq+0mmBgwHMpORWtiy754Ty5P+LuS/egclMZipFng0uj674yx6w=<br>
=mxbF<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
Commotion-discuss mailing list<br>
<a href="mailto:Commotion-discuss@lists.chambana.net">Commotion-discuss@lists.chambana.net</a><br>
<a href="https://lists.chambana.net/mailman/listinfo/commotion-discuss" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-discuss</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div>Ben West</div><div><a href="mailto:me@benwest.name" target="_blank">me@benwest.name</a></div>
</div>