Re: [B.A.T.M.A.N.] Basic Multicast Optimizations

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

[-- Attachment #1: Type: text/plain, Size: 2002 bytes --]

On Wed, Jun 12, 2013 at 02:27:14PM +0200, Linus Lüssing wrote:
> On Wed, Jun 12, 2013 at 12:14:11PM +0200, Simon Wunderlich wrote:
> > Hello Linus,
> > 
> > I gave it a try - but there seems something off. What I did is:
> >  * apply your patches on 3b38a80 - multicast was enabled by default
> >  * start 2 VMs directly connected
> >  * ping6 -I bat0 ff02::1
> > 
> > I only got a reply locally, but not from the peer. When I disabled
> > multicast, I got two replies from the local host and the peer.
> > 
> > As far as I have tracked the problem down, it appears that
> > batadv_mcast_forw_mode() returns 1 correctly, but the packet is dropped
> 
> Ok, found a bug - the return 1 is actually incorrect. You've
> chosen the one multicast address where no optimization is
> conceptually possible. ff02::1 is the only link-local IPv6
> multicast address which should return a BATADV_FORW_ALL (0)
> instead.

Ah, wonderful, and I thought I found a testcase. :D

Can you advise how the feature can be tested then, practically?
I guess I'll need to add some routes and ping6 another address?

> 
> (Conceptually impossible because for ff02::1 is the one multicast
> address which by the IPv6 standard every host listens to, without
> performing any MLD.)
> 
> I'll add another check next to the scope check in
> mcast_forw_mode().
> 
> > later in the process - I would guess that this happens in
> > batadv_send_generic_unicast_skb() where we try to select the gateway
> > when the destination mac is multicast instead of looking it up in the
> > tt table. But I leave the details to you. :)
> 
> Hm, but still, you're right, with this single destination, the
> other VM, the ICMPv6 request and reply should have arrived because
> the according MAC (33:33:00:00:00:01) is in the global translation table.

Yeah, it was, that is what puzzled me.
> 
> I didn't have that issue in my tests so far, I'll try to reproduce
> that issue.

OK.

Thanks,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]