From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lh4E4-0006q8-TW for qemu-devel@nongnu.org; Tue, 10 Mar 2009 11:50:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lh4E4-0006pv-GU for qemu-devel@nongnu.org; Tue, 10 Mar 2009 11:50:40 -0400 Received: from [199.232.76.173] (port=42465 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lh4E4-0006ps-Ao for qemu-devel@nongnu.org; Tue, 10 Mar 2009 11:50:40 -0400 Received: from silmor.de ([217.160.219.75]:2267 helo=p15139323.pureserver.info) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lh4E3-00025g-Ly for qemu-devel@nongnu.org; Tue, 10 Mar 2009 11:50:40 -0400 Received: from chris by p15139323.pureserver.info with local (Exim 4.63) (envelope-from ) id 1Lh4Dx-000549-Ue for qemu-devel@nongnu.org; Tue, 10 Mar 2009 16:50:33 +0100 Date: Tue, 10 Mar 2009 16:50:33 +0100 From: Christian Perle Message-ID: <20090310155033.GB8323@silmor.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] Solution for qemu mcast / ipv6? Reply-To: chris@linuxinfotag.de, 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 Hello there, We are using qemu's multicast networking feature (-net socket,mcast=...) to connect some qemu instances (running linux guests) to each other. Qemu's multicast networking code sets socket option IP_MULTICAST_LOOP to make communication between local qemu instances possible. So each qemu gets all the traffic, including its own. This works fine as long as no ipv6 is used. Because ipv6 has a built-in duplicate address detection (DAD) and each qemu instance sees its own traffic, DAD will always detect a ipv6 address collision although there is none. Our solution is to patch the function qemu_send_packet() so it drops packets from source mac address X if the network interface the packet is being sent to has the same mac address X. The patch adds a new member "macaddress" to the VLANClientState struct which is filled by qemu_format_nic_info_str() during interface initialization. An additional check in qemu_send_packet() decides if the packet must be dropped. ---------------------------------------------------------------------- diff -ru qemu-0.10.0.orig/net.c qemu-0.10.0/net.c --- qemu-0.10.0.orig/net.c 2009-03-04 23:54:45.000000000 +0100 +++ qemu-0.10.0/net.c 2009-03-06 16:38:09.000000000 +0100 @@ -303,6 +303,13 @@ 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]; } static char *assign_name(VLANClientState *vc1, const char *model) @@ -407,6 +414,19 @@ #endif for(vc = vlan->first_client; vc != NULL; vc = vc->next) { if (vc != vc1 && !vc->link_down) { + /* + * Workaround for IPv6 DAD problem + * note: this assumes offset 6 for src mac + */ + if (size >= 12) { + if (0 == memcmp(buf+6, &(vc->macaddress), + sizeof(vc->macaddress))) { +#ifdef DEBUG_NET + printf("ignore own packet for %s\n", vc->info_str); +#endif + continue; + } + } vc->fd_read(vc->opaque, buf, size); } } diff -ru qemu-0.10.0.orig/net.h qemu-0.10.0/net.h --- qemu-0.10.0.orig/net.h 2009-03-04 23:54:45.000000000 +0100 +++ qemu-0.10.0/net.h 2009-03-06 16:06:04.000000000 +0100 @@ -24,6 +24,8 @@ struct VLANState *vlan; char *model; char *name; + /* mac address in binary format for quick matching */ + uint8_t macaddress[6]; char info_str[256]; }; ---------------------------------------------------------------------- Now the question: Is this a proper solution? Does it break anything? So far we haven't seen any regression. It would be nice to have this in standard qemu, maybe as a configurable option. Greetings, Chris -- Christian Perle chris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing