From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMYKi-0001cS-I5 for qemu-devel@nongnu.org; Mon, 01 Apr 2013 02:35:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMYKf-0006Ez-Po for qemu-devel@nongnu.org; Mon, 01 Apr 2013 02:35:08 -0400 Received: from 69.169.164.127.provo.static.broadweavenetworks.net ([69.169.164.127]:37929 helo=baldr.dev-zero.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMYKf-0006CI-Ka for qemu-devel@nongnu.org; Mon, 01 Apr 2013 02:35:05 -0400 Message-ID: <51592A97.1050305@dev-zero.net> Date: Mon, 01 Apr 2013 00:35:03 -0600 From: Mike Lovell MIME-Version: 1.0 References: <20130305163510.GC3177@type.bordeaux.inria.fr> <20130306122937.GD1954@stefanha-thinkpad.muc.redhat.com> <20130306131525.GC6173@type.bordeaux.inria.fr> <20130307093826.GE13854@stefanha-thinkpad.redhat.com> <20130307171428.GC6043@type.bordeaux.inria.fr> <20130308084318.GA8984@stefanha-thinkpad.redhat.com> <20130308090855.GT5863@type.youpi.perso.aquilenet.fr> <20130308124737.GS5863@type.youpi.perso.aquilenet.fr> In-Reply-To: <20130308124737.GS5863@type.youpi.perso.aquilenet.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: Samuel Thibault , Stefan Hajnoczi , ped@listes.subiron.org, qemu-devel@nongnu.org On 03/08/2013 05:47 AM, Samuel Thibault wrote: > Samuel Thibault, le Fri 08 Mar 2013 10:08:55 +0100, a =E9crit : >> There does exist some unique address, which is returned by recvfrom, >> I'll have a look at how to get access to it. > Ah, no, it's not unique... It's just the host IP address and the same > port as the multicast address, so it'll be the same for all qemus on th= e > same host. I've checked how Linux bounces the datagram, it's through > the loopback interface, and thus dispatched over all listeners without > distinction. I don't see any way to get the information that the packet > comes from us, except using the ethernet content. this is actually a problem that i dealt with when i was building the=20 switched multicast backend i did last year. (=20 http://lists.nongnu.org/archive/html/qemu-devel/2012-06/msg04082.html ) one solution is to actually use two sockets. one that is bound to the=20 multicast address, which receives the multicast packets, and another=20 that is just bound to any ephemeral udp port, which is used for sending=20 packets. when a packet is to be sent out to the multicast address, call=20 sendto on the ephemeral socket with a destination of the multicast=20 address. then, using recv_from on the multicast socket, packets being=20 received can be compared to the local ephemeral address. if the address=20 on the recv_from matches the address for the local ephemeral socket, the=20 packet can just be dropped. no inspection of the packet being passed=20 around is needed in this case. if the group is interested is a solution like this, i can probably make=20 some time over the next couple days to cook up a patch. thoughts? mike