From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LhBnf-0003cx-83 for qemu-devel@nongnu.org; Tue, 10 Mar 2009 19:55:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LhBnd-0003cl-4C for qemu-devel@nongnu.org; Tue, 10 Mar 2009 19:55:53 -0400 Received: from [199.232.76.173] (port=47608 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LhBnc-0003ci-Vu for qemu-devel@nongnu.org; Tue, 10 Mar 2009 19:55:53 -0400 Received: from mail2.shareable.org ([80.68.89.115]:50532) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LhBnc-0005H4-IP for qemu-devel@nongnu.org; Tue, 10 Mar 2009 19:55:52 -0400 Date: Tue, 10 Mar 2009 23:55:47 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Solution for qemu mcast / ipv6? Message-ID: <20090310235547.GE27500@shareable.org> References: <20090310155033.GB8323@silmor.de> <200903101611.38454.paul@codesourcery.com> <20090310203017.GC8323@silmor.de> <200903102316.14749.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200903102316.14749.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: chris@linuxinfotag.de Paul Brook wrote: > > > The bug is in the the mcast socket code. You need to fix that to stop > > > looping back all the packets. > > > > Do you mean the mcast socket code in qemu or the way IP_MULTICAST_LOOP > > works in the linux kernel? > > I don't know. Hacking the generic vlan code is definitely the wrong solution > though. I suspect there's no suitable kernel option, and this is for all hosts, not just Linux. One solution is filtering in the userspace code which talks to the socket. Filtering by MAC address is wrong as Paul has explained. So the filtering which comes to mind is (a) keep _strong_ checksums of all recently sent packets, (b) discard any received packets which match a recently sent one, and (c) make sure to remove any checksum when it matches in (b), because it's legitimate for the _same_ packet to arrive from another host soon after, and that should not be filtered. Alternatively, presuming the idea is to tunnel raw ethernet packets into a multicast IP packet, change the tunnelled format slightly to include a unique sender identifier, and filter on that. That's unambiguous. -- Jamie