Open-Mesh » batman-adv

Linus Lüssing wrote:

Trying to assign a static multicast listener to bat0 fails with the following command:

[...]

Funnily, adding a bridge br0 on top of bat0 and then assigning the listener to br0 instead works fine.

Kernel: 3.8.1
ip utility, iproute2-ss120521

sounds like batman-adv needs to implement some ioctl operation for this. we can look at the bridge code to learn what to do.

any pointer to what this listener exactly is?
moreover, does Batman-adv really need to implement it? or we can directly rely on a upper bridge?

Antonio Quartulli wrote:

any pointer to what this listener exactly is?

This listener basically means telling the device/kernel to configure everything in a way to be able to receive frames for the specified address. Afaik some hardware devices support filtering multicast addresses in hardware. And 'ip maddr add' allows to tell the kernel to tell the device which addresses not to filter (see this handler for the FEC driver for an example). While for IP the kernel will do that without the need of 'ip maddr add', for non-IP frames 'ip maddr add' is probably useful, I guess.

moreover, does Batman-adv really need to implement it? or we can directly rely on a upper bridge?

No, we do not need to implement that. Actually being able to set that with the ip utility doesn't change anything at the moment. We receive any multicast frame at the moment anyway, no matter if we set a specific link layer address or not.

At first I thought that with 'ip maddr add' I'd be able to add static IP multicast listeners, too, but trying 'ip maddr add ff12::123 dev $DEV' doesn't work in general. Which would have been a nice thing to have as many userspace tools, including netcat, do allow listening to a multicast ip address but do not perform the ioctl() operation to join the group. The ip utility would have been a nice thing to do that.

So for now the patch posted to the mailing list does not actually change anything for practical use-cases. But it is probably more consistent as many virtual devices, like the bridge or virtio-net (there's a similar change/bugreport here), do the same.

And it'll be helpful for debugging purposes with the multicast optimizations, as the first basic patches simply only iterate over the link layer multicast addresses, with these static link-layer multicast listeners included, for their announcement. So I'm able to do an 'ip maddr add ...' and that node will then start to receive the according IPv6 link-local multicast packets, too, without needing to create a dynamic IP multicast listener through heavy tools like vlc first, for instance.