From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCupu-0004xd-VQ for qemu-devel@nongnu.org; Tue, 05 Mar 2013 11:35:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCupm-0006K1-KS for qemu-devel@nongnu.org; Tue, 05 Mar 2013 11:35:30 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:36105) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCupm-0006Gu-Ei for qemu-devel@nongnu.org; Tue, 05 Mar 2013 11:35:22 -0500 Date: Tue, 5 Mar 2013 17:35:10 +0100 From: Samuel Thibault Message-ID: <20130305163510.GC3177@type.bordeaux.inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] socket,mcast looping back frames -> IPv6 broken List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: ped@listes.subiron.org Hello, The reason why IPv6 does not work when using -net socket,mcast=foo is that since qemu explicitly sets IP_MULTICAST_LOOP to 1, it receives its own frames. When the IPv6 stack performs duplicate addresse detection (DAD) through a multicasted announce, it receives its own announcement, and thus believes another machine has the same address. AIUI, on a real physical network network boards do not receive the multicasts they send, so the issue does not happen. Perhaps some boards even filter out any frame with its own MAC as source, eliminating the issue altogether. As a result, we should probably perform this kind of dropping, I'm just wondering at which level that would be preferable. - We could do that in qemu_send_packet_async_with_flags, thus fixing the issue for all kinds of frame transporters. - Or we could do that for the only case that matters, mcast, in net_socket_send_dgram (which will thus do it for the unicast udp case too). What do people think about it? Samuel