Re: [Qemu-devel] [Bug 1404278] Re: tap connections not working on windows host

From: Stefan Hajnoczi <1404278@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1404278] Re: tap connections not working on windows host
Date: Wed, 07 Jan 2015 09:06:30 -0000	[thread overview]
Message-ID: <20150107090630.GA18014@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: 20150106211253.22105.53074.malone@gac.canonical.com

On Tue, Jan 06, 2015 at 09:12:53PM -0000, timsoft wrote:
> output as requested from the guest:
>  ip addr
> 1: lo: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state 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(Preferred)
>    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-EE-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:fed6(Prefe
> rred)
>    Link-local IPv6 Address . . . . . : fe80::3005:1b7:f5fe:fed6%13(Preferred)
>    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=tap01 -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 adapter (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 default 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