From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Lh4YT-0008Oq-Cx
	for qemu-devel@nongnu.org; Tue, 10 Mar 2009 12:11:45 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Lh4YR-0008Nx-M6
	for qemu-devel@nongnu.org; Tue, 10 Mar 2009 12:11:44 -0400
Received: from [199.232.76.173] (port=52648 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Lh4YR-0008No-F1
	for qemu-devel@nongnu.org; Tue, 10 Mar 2009 12:11:43 -0400
Received: from mx20.gnu.org ([199.232.41.8]:31030)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1Lh4YR-0006ee-6t
	for qemu-devel@nongnu.org; Tue, 10 Mar 2009 12:11:43 -0400
Received: from mail.codesourcery.com ([65.74.133.4])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1Lh4YP-00015q-GG
	for qemu-devel@nongnu.org; Tue, 10 Mar 2009 12:11:41 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Solution for qemu mcast / ipv6?
Date: Tue, 10 Mar 2009 16:11:37 +0000
References: <20090310155033.GB8323@silmor.de>
In-Reply-To: <20090310155033.GB8323@silmor.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200903101611.38454.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org, chris@linuxinfotag.de

Using diff -up makes patches much easier to review.

> @@ -303,6 +303,13 @@ qemu_format_nic_info_str
>               vc->model,
>               macaddr[0], macaddr[1], macaddr[2],
>               macaddr[3], macaddr[4], macaddr[5]);
> +    /* copy mac address into struct for quick matching */
> +    vc->macaddress[0] = macaddr[0];
> +    vc->macaddress[1] = macaddr[1];
> +    vc->macaddress[2] = macaddr[2];
> +    vc->macaddress[3] = macaddr[3];
> +    vc->macaddress[4] = macaddr[4];
> +    vc->macaddress[5] = macaddr[5];
>  }

This is almost certainly the wrong place to do this.

> Now the question: Is this a proper solution? 

No.

> Does it break anything? 

Yes.

You can't make any assumptions about MAC addresses. The guest may choose to 
use a different MAC address, or it may be acting as a hub/switch and 
generating packets from many different MAC addresses.

The bug is in the the mcast socket code. You need to fix that to stop looping 
back all the packets.

Paul