respondd should make use of address ff05::2:1001 for mesh-wide broadcasts and use ff02::2:1001 for talking to its neighbors

[christf]

this will work for both batman and babel networks but enable respondd-usage in babel networks.

this affects https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-respondd/files/etc/init.d/gluon-respondd#L22

also it may be reasonable to extend respondd to handle teh distinction between ff02 and ff05

[T-X]

For batman-adv meshes I would prefer sticking to ff02 for now. At least until MRD (multicast router discovery) snooping is implemented in the bridge + batman-adv.

[christf]

does this mean I should split the package for now?

[neocturne]

Please don't split the package. I'd really like to keep this consistent and switch the address to ff05::2:1001 for batman-adv as well.

I think the batman-adv multicast optimizations won't help here much; as long as respondd runs on all nodes, the package will need to reach every node anyways.

[christf]

ok. I am using an upgrade script for now that modifies the initscript form respondd to obtain a testable babel firmware. This script can be removed easily once the address is changed globally

[jplitza]

Can't we simply let respondd join both multicast groups?

[christf]

Can't we simply let respondd join both multicast groups?

At the moment it seems respondd does not support that.

[jplitza]

No it doesn't, and implementing it doesn't seem to be as easy as I first thought. But that seems to be the cleanest solution to me.

[christf]

so. what shall it be?
a) extend respondd to join multiple multicast-groups

[christf]

b) use ff05 for batman and babel-networks?

[christf]

... what is actually to be done before batman-based networks can switch to ff05?

[T-X]

Ideally, the following would be done:

a) make the bridge join the "All-Snoopers-Multicast" address
b) make the bridge parse Multicast Router Advertisement and Multicast Router Termination messages and update its internal router list accordingly
c) make batman-adv parse the same messages to update its "WANT_ALL_IPV4" and "WANT_ALL_IPV6" multicast flags accordingly
d) then change a line in batman-adv to apply multicast optimizations for a multicast scope greater than link-local, too

Optionally, but recommended:

e) Make the bridge and/or batman-adv send Multicast Router Solicitations in some useful way.
f) If a bridge port is configured with "multicast_router = 2", then make the bridge send Multicast Router Advertisements on all other ports.

MRD is actually a pretty simple protocol, nothing compared to IGMP/MLD. And the infrastructure is basically already there (like there is a router list in the bridge already). So it is mostly about writing some MRD parsing code in the kernel.

On the other hand, @NeoRaider is right, if you have many receivers listening on your ff05 address (here: every node?), then we cannot apply batman-adv multicast optimizations and flooding is our only option again.

So I'm ok-ish with changing it to ff05 for this case where every node is supposed to listen to the address.

[christf]

well, that would mean we could switch now by just changing the above initscript.