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(a)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(a)lists.sudoroom.org
https://sudoroom.org/lists/listinfo/mesh-dev