[Battlemesh] legal wifi channels for mesh

Daniel Golle daniel at makrotopia.org
Wed Feb 14 16:39:39 UTC 2018


On Wed, Feb 14, 2018 at 05:58:03PM +0200, Jonathan Morton wrote:
> > On 14 Feb, 2018, at 5:34 pm, guifipedro <guifipedro at gmail.com> wrote:
> > 
> > Right now I only have rumours and I would like to know if someone has
> > good references (links to text or graphics) that shows what are the
> > available channels for use in mesh for 2.4 and 5 GHz in case of using
> > openwrt or lede (concerning DFS [1] restrictions). Is the same for all
> > european countries?
> 
> The most reliable information is probably from the regulatory database, here:
> 
> 	https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/tree/db.txt
> 
> The first entry in that file is the "world" region, which lists some channels which should always be available.
> 

> It's probably worth contrasting three EU countries' entries, FI, FR and GB:
> ...
> 	(5470 - 5725 @ 160), (27), DFS
> ...
> 	(5490 - 5710 @ 160), (27), DFS
> ...
> 	(5490 - 5710 @ 160), (27), DFS


Given that 802.11s can theoretically support DFS channels when using
wpa_supplicant it could be worth building a version of wpad which does
support the mesh interface type but does not include SAE crypto (which
pulls in openssl libs). With that we could evaluate if running a mesh
interface with channel set to 'auto' would allow us using DFS channels
(it for sure doesn't work without wpa_supplicant and also most likely
won't work out-of-the-box when using it...)

I also thought about adding a 'preferred channel' option similar to
how proprietary firmware allows to set DFS channels for AP mode. We
could even have a static list of alternative channels to be tried (ie.
scanned) in case a radar pulse is received by a participating node.

The easiest logic would be to iterate over that list in reverse order
and scan for the mesh_id. In case it is found, join it.
If the mesh_id cannot be found at all, now iterate over the list in
forward order and use the first channel available (ie. no radar pulses
reported).
Regularly repeat the procedure, so hidden nodes which did not end up
on the same channel are discovered and the rest of the mesh then pulled
to that new channel.

This of course can only work under some basic assumptions:
 * communities monitor for radar pulses in the geographic area they
   are active in.
   In my experience, actually finding radar pulses is pretty rare
   and if any, then they are detected on the same frequency in a
   rather large area.
 * communities then wisely choose a list of currently available
   channels with identical TX power


Implementing the missing parts as a patch for wpa_supplicant shouldn't
be terribly hard and if there is interest in that, I'm willing to go
deeper into it and also research if there is anything mentioned about
DFS in the 802.11s standard (I only know parts of the implementation
for now)


Cheers


Daniel


More information about the Battlemesh mailing list