[mesh-dev] Multicast forwarding for layer 3 pseudo-bridges

max b maxb.personal at gmail.com
Wed Jun 24 21:34:24 PDT 2015


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 at 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 at lists.sudoroom.org
> https://sudoroom.org/lists/listinfo/mesh-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh-dev/attachments/20150624/b32912de/attachment.html>


More information about the mesh-dev mailing list