From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8r7t-0000f3-W2 for qemu-devel@nongnu.org; Wed, 07 Jan 2015 08:58:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y8r7o-0007th-K4 for qemu-devel@nongnu.org; Wed, 07 Jan 2015 08:58:21 -0500 Received: from indium.canonical.com ([91.189.90.7]:41876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8r7o-0007rn-FC for qemu-devel@nongnu.org; Wed, 07 Jan 2015 08:58:16 -0500 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.76 #1 (Debian)) id 1Y8miL-00081U-FY for ; Wed, 07 Jan 2015 09:15:41 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 6CB692E8086 for ; Wed, 7 Jan 2015 09:15:41 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 07 Jan 2015 09:06:30 -0000 From: Stefan Hajnoczi <1404278@bugs.launchpad.net> Sender: bounces@canonical.com References: <20141219153639.25009.84583.malonedeb@wampee.canonical.com> <20150106211253.22105.53074.malone@gac.canonical.com> Message-Id: <20150107090630.GA18014@stefanha-thinkpad.redhat.com> Errors-To: bounces@canonical.com Subject: Re: [Qemu-devel] [Bug 1404278] Re: tap connections not working on windows host Reply-To: Bug 1404278 <1404278@bugs.launchpad.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Tue, Jan 06, 2015 at 09:12:53PM -0000, timsoft wrote: > output as requested from the guest: > ip addr > 1: lo: mtu 65536 qdisc noqueue state UNKOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: mtu 1500 qdisc pfifo_fast stat= e UP qlen 1000 > link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff > inet 10.1.1.143/24 brd 10.1.1.255 scope global eth0 > valid_lft forever preferred_lft forever > inet6 fe80::5054:ff:fe12:3456/64 scope link > valid_lft forever prefered_lft forever > = > ip route > default via 10.1.1.88 dev eth0 metric 1 > 10.1.1.0/24 dev eth0 proto kernel scope link src 10.1.1.143 > 127.0.0.0/8 dev lo scope link > = > iptables -L -n > Chain INPUT (policy ACCEPT) > target prot opt source destination > = > Chain FORWARD (policy ACCEPT) > target prot opt source destination > = > Chain OUTPUT (policy ACCEPT) > target prot opt source destination The output from the guest shows that IP traffic from guest to host or external network should go through 10.1.1.88. When you watch traffic inside the guest, you should see ARP Who-Has 10.1.1.88 to look up the MAC address of the gateway. If a response makes it back to the guest, then the guest will send IP packets with the Ethernet destination address of the gateway. This approach depends on the host bridging traffic between the physical network and the guest... > the output of ipconfig /all on the windows host is as follows > Windows IP Configuration > = > Host Name . . . . . . . . . . . . : timoffice > Primary Dns Suffix . . . . . . . : > Node Type . . . . . . . . . . . . : Hybrid > IP Routing Enabled. . . . . . . . : No > WINS Proxy Enabled. . . . . . . . : No > = > Ethernet adapter netbridge: > = > Connection-specific DNS Suffix . : > Description . . . . . . . . . . . : MAC Bridge Miniport > Physical Address. . . . . . . . . : 02-FF-9A-6A-E7-7C > DHCP Enabled. . . . . . . . . . . : No > Autoconfiguration Enabled . . . . : Yes > Link-local IPv6 Address . . . . . : fe80::24f3:ff1d:12cb:5fbb%16(Prefe= rred) > IPv4 Address. . . . . . . . . . . : 10.1.1.41(Preferred) > Subnet Mask . . . . . . . . . . . : 255.255.255.0 > Default Gateway . . . . . . . . . : 10.1.1.88 > DHCPv6 IAID . . . . . . . . . . . : 469958554 > DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1B-E0-26-A3-BC-5F-F4-E= E-19-98 > = > DNS Servers . . . . . . . . . . . : 10.1.1.88 > NetBIOS over Tcpip. . . . . . . . : Enabled So far, so good. > Tunnel adapter isatap.{03958EF2-282D-45A7-9B98-0E447AA401A0}: > = > Media State . . . . . . . . . . . : Media disconnected > Connection-specific DNS Suffix . : > Description . . . . . . . . . . . : Microsoft ISATAP Adapter > Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 > DHCP Enabled. . . . . . . . . . . : No > Autoconfiguration Enabled . . . . : Yes > = > Tunnel adapter Teredo Tunneling Pseudo-Interface: > = > Connection-specific DNS Suffix . : > Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface > Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 > DHCP Enabled. . . . . . . . . . . : No > Autoconfiguration Enabled . . . . : Yes > IPv6 Address. . . . . . . . . . . : 2001:0:9d38:90d7:3005:1b7:f5fe:fed= 6(Prefe > rred) > Link-local IPv6 Address . . . . . : fe80::3005:1b7:f5fe:fed6%13(Prefer= red) > Default Gateway . . . . . . . . . : :: > NetBIOS over Tcpip. . . . . . . . : Disabled Not sure why there are two tunnel adapters with the same 00-00-00-00-00-00-00-E0 MAC address. Could be a Windows thing, I haven't used tun/tap under Windows. Stefan -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1404278 Title: tap connections not working on windows host Status in QEMU: New Bug description: using latest qemu 2.2.0 64bit for windows host (installed from qemu-w64-setup-20141210.exe obtained from http://qemu.weilnetz.de/w64/ ),OpenVPN 2.6.3-I601 64bit tap adapter named tap01 and calling qemu using the following. qemu-system-x86_64.exe -m 512 -net nic -net tap,ifname=3Dtap01 -hda "c:\\data\\images\\test.img" where the image contains a slackware 14.0 64bit install. The tap is bridged with the real network adapter and the bridge is given = an ip of 10.1.1.41 (which works as the ip for the windows host). The tap ad= apter (in network connections) shows connected when the qemu vm is running.= inside the vm, the network is given an ip of 10.1.1.143 (the netmask and d= efault gateway are the same for the virtual and real pc). fault. The vm cannot see the rest of the local network or visa-versa. This used = to work in early (0.9 32bit) versions of qemu. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1404278/+subscriptions