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.
(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.
I didn't have that issue in my tests so far, I'll try to reproduce that issue.
The rest looks good, but I'll review more deeply again when it's actually working. It does compile without problems now.
Cheers, Simon
Thanks for the feedback again!
Cheers, Linus