Hi,

Just to clear up routing/bridging of multicast:

for routing, it's where you have multiple IPv4/IPv6 interfaces you are
routing, and you want to watch for multicast group requests and pass
them on, then forward traffic as appropriate between interfaces for a
given multicast group /only/ if someone is subscribed to it. Otherwise
you have to forward all multicast traffic, and it's unfun. By default
noone routes multicast because, well, reasons.

I've forgotten about multicast and TTL stuff, and whether multicast
routing requires a star/acyclic graph to ensure you don't get
broadcast storms/loops.

for multicast switching, it's mostly just "sniff multicast group
requests (IGMP snooping)" and don't forward multicast for other
groups. Except for certain circumstances, it's pretty useful in
cutting down massive amounts of multicast traffic that by default
you'd have to flood to each port like any other broadcast. Now, for
wifi, it's /totally/ possible to do intelligent things with multicast
snooping, but I hope that this is just using broadcast/multicast for
discovery, rather than passing real data. (You can do
multicast-to-unicast, then only forward streams that clients request.)

broadcast/multicast is spendy on wifi and double-spendy on 11s because
of how traffic gets replicated. So as long as it's for peer discovery,
cool.

Final dotpoint - if it's using UDP broadcast instead of multicast, you
may find mrouted doesn't help - but then writing a little application
to 'route' those announcements between subnets may not be /that/ hard.
So, is it using multicast to do peer discovery, or is it doing
broadcasts? Has anyone spun it up and done some packet dumps to see?

-adrian