Just a thought - what exactly does using adhoc buy us here? I imagine that our extender nodes will likely be either pt->pt or pt->multipoint, each of which would be supported by an AP->Station mode. I guess that it might be slightly more convenient to just throw extender nodes into adhoc and not worry about them, but generally we'll have to select channels anyhow, so is it much harder just to choose station or AP mode? 

If we were to abandon adhoc mode, can we use WDS in order to bridge extender nodes?

On Wed, Jun 24, 2015 at 10:02 AM, Jernej Kos <jernej@kos.mx> wrote:
Hello!

On 24. 06. 2015 18:55, Dave Taht wrote:
>> Running babeld is a solution, but not ideal since it makes Babel deal with
>> extender-nodes as real nodes, adding more signalling traffic to the network
>> which should be unnecessary and complicates our network graphs.
>
> The signalling traffic is trivial. (especially compared to bridging
> multicast????)
>
> The complications are possibly beneficial. I have gone through hell
> finding weird
> bridged networks in the path.

I have to agree with Dave here. I prefer to have more transparency (even
if it increases the topology a little) instead of bridges that can't be
seen and are hard to debug.

I understand your case for wanting to forward mDNS traffic over L3, but
why would you want to bridge Babel multicast? This will just hide
potential problems when they occur.


Jernej


_______________________________________________
mesh-dev mailing list
mesh-dev@lists.sudoroom.org
https://sudoroom.org/lists/listinfo/mesh-dev