On Wed, Jun 24, 2015 at 4:07 AM, Marc Juul <juul@labitat.dk> wrote:
> # The problem
>
> Our extender-nodes can't bridge their adhoc wifi interface to their ethernet
> interface since bridging adhoc is not possible. A layer 3 pseudo-bridge
> using relayd should work but both Babel and mDNS rely on multicast which is
> not handled by relayd.
>
> # Solutions
>
> It looks like we have two options:
>
> 1. Forward both babel and mDNS IPv4 and IPv6 multicast messages between
> interfaces selectively based on the multicast addresses of these protocols
> 2. Have extender-nodes forward / route multicast traffic in general
> (pimd/pim6sd).

pimd is horribly ill-maintained. I have not seen it work right in many cases.

>
> 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.

> ## Selective multicast routing/forwarding
>
> mDNS has existing solutions available, such as:
>
> * avahi with enable-reflector option (kinda bulky)
> * mdns-repeater (no openwrt package exists)

The in-progress solution to unicast mdns discovery is the mdns hybrid
proxy work spearheaded by stuart chesire at the ietf.

https://tools.ietf.org/html/draft-cheshire-dnssd-hybrid-01

Code: https://github.com/sbyx/ohybridproxy

I have pimd in ceropackages. Does not work well.

quagga had pim support enter it recently. That codebase looked promising.

> If we wanted to avoid pimd, then we could disable mDNS on IPv4, which
> shouldn't present a problem since all mesh-connected devices will have IPv6
> addresses anyway, but it's probably unlikely that babeld can function on
> both IPv4 and IPv6 without IPv4 multicast (unless we change a bunch of
> code). Totally worth checking if it already has that ability though, since
> avoiding IPv4 multicast would be a bonus.

Babel does not use ipv4 at all. All multicast is ipv6. Babel can carry
both ipv4 and ipv6 in it´s ipv6 packets.

Babel when using source specific routing and falls back to multiple
ipv6 routing tables when ipv6_subtrees is not available. ipv6_subtrees
is enabled by default in BB and later.

> # Conclusion
>
> I propose that we run babeld on the extender nodes and use avahi as a
> reflector for now. We can then revisit this for e.g. version 0.4.
>
> What do you all say?

I shipped avahi as a reflector in cerowrt. It caused broadcast storms
with more than three nodes interconnected. It also went nuts when a
device was on more than one subnet and announced itself, doing things
like renumbering nodea-1 to nodea-2,3,4,5,6 (I dont think avahi is RFC
compliant here)

You are SOL.

> Based on this preliminary research it looks like the long-term solution
> involving the smallest amount of work is probably running pim6sd and pimd.
> This is gratifying since it would be really cool to have a mesh that does
> real actual multicast routing.

I would like pimd to work well also. However the code path in the
kernel is underutilized, horribly undertested, and I think you are
dreaming.