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