From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDEBs-0006tR-Is for qemu-devel@nongnu.org; Wed, 06 Mar 2013 08:15:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDEBr-0005ok-Cn for qemu-devel@nongnu.org; Wed, 06 Mar 2013 08:15:28 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:29826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDEBr-0005oR-6q for qemu-devel@nongnu.org; Wed, 06 Mar 2013 08:15:27 -0500 Date: Wed, 6 Mar 2013 14:15:25 +0100 From: Samuel Thibault Message-ID: <20130306131525.GC6173@type.bordeaux.inria.fr> References: <20130305163510.GC3177@type.bordeaux.inria.fr> <20130306122937.GD1954@stefanha-thinkpad.muc.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130306122937.GD1954@stefanha-thinkpad.muc.redhat.com> Subject: Re: [Qemu-devel] [PER] Re: socket, mcast looping back frames -> IPv6 broken List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ped@listes.subiron.org Cc: qemu-devel@nongnu.org Stefan Hajnoczi, le Wed 06 Mar 2013 13:29:37 +0100, a écrit : > On Tue, Mar 05, 2013 at 05:35:10PM +0100, Samuel Thibault wrote: > > 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. > > The reason for IP_MULTICAST_LOOP is to allow QEMU processes running on > the same host to communicate with each other. Sure, I've seen the comment, I wasn't suggesting to drop that :) > > 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? > > We should fix the layer that introduces the problem. Therefore I think > the fix needs to be net/socket.c. Ok. > Unfortunately net/socket.c does not have the concept of a link-layer > address, so we cannot easily filter out multicast packets coming from > our NIC's address. > > Are you aware of a way to filter out just the packets sent by *this* > process? I haven't seen any in the Linux source code. One thing that should work, however, is to use recvfrom, and drop whatever comes from our sockname. Samuel