tap connections not working on windows host
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
using latest qemu 2.2.0 64bit for windows host (installed from qemu-w64-
qemu-system-
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.
timsoft (tim-tree-of-life) wrote : | #1 |
Stefan Hajnoczi (stefanha) wrote : Re: [Qemu-devel] [Bug 1404278] [NEW] tap connections not working on windows host | #2 |
On Fri, Dec 19, 2014 at 03:36:39PM -0000, timsoft wrote:
> using latest qemu 2.2.0 64bit for windows host (installed from
> qemu-w64-
> ),OpenVPN 2.6.3-I601 64bit tap adapter named tap01 and calling qemu
> using the following.
>
> qemu-system-
> "c:\\data\
>
> 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.
Please try tcpdump or Wireshark on guest and host to check whether ping
works in either direction.
Stefan
timsoft (tim-tree-of-life) wrote : | #3 |
have used wireshark on host and nothing is coming through when I try to ping the host from the client. (bare with me as I haven't used wireshark before).
I'm just upgrading the client to slack64 14.1 so I can get wireshark running on it. (process is a little slow, especially with no functioning network on the client). If all goes well, I'll be able to test that by tomorrow (it took about 5hours to install last time). I'll then post back here.
If there are any specific tests or methods I could follow that would help please let me know.
Stefan Hajnoczi (stefanha) wrote : Re: [Qemu-devel] [Bug 1404278] Re: tap connections not working on windows host | #4 |
On Mon, Jan 05, 2015 at 05:11:50PM -0000, timsoft wrote:
> have used wireshark on host and nothing is coming through when I try to ping the host from the client. (bare with me as I haven't used wireshark before).
> I'm just upgrading the client to slack64 14.1 so I can get wireshark running on it. (process is a little slow, especially with no functioning network on the client). If all goes well, I'll be able to test that by tomorrow (it took about 5hours to install last time). I'll then post back here.
> If there are any specific tests or methods I could follow that would help please let me know.
Please post the following output from the guest:
# ip addr
# ip route
# iptables -L -n
This way we can verify that the guest's network interface is configured,
up, and has no firewall rules that could filter packets.
Please post output from the "ipconfig /all" command on the Windows host.
Stefan
timsoft (tim-tree-of-life) wrote : | #5 |
- screenclip of host network connections Edit (40.3 KiB, image/jpeg)
output as requested from the guest:
ip addr
1: lo: <LOOPBACK,
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,
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:
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 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-
Description . . . . . . . . . . . : MAC Bridge Miniport
Physical Address. . . . . . . . . : 02-FF-9A-6A-E7-7C
DHCP Enabled. . . . . . . . . . . : No
Autoconfigur
Link-local IPv6 Address . . . . . : fe80::24f3:
IPv4 Address. . . . . . . . . . . : 10.1.1.
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.1.88
DHCPv6 IAID . . . . . . . . . . . : 469958554
DHCPv6 Client DUID. . . . . . . . : 00-01-00-
DNS Servers . . . . . . . . . . . : 10.1.1.88
NetBIOS over Tcpip. . . . . . . . : Enabled
Tunnel adapter isatap.
Media State . . . . . . . . . . . : Media disconnected
Connection-
Description . . . . . . . . . . . : Microsoft ISATAP Adapter
Physical Address. . . . . . . . . : 00-00-00-
DHCP Enabled. . . . . . . . . . . : No
Autoconfigur
Tunnel adapter Teredo Tunneling Pseudo-Interface:
Connection-
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 00-00-00-
DHCP Enabled. . . . . . . . . . . : No
Autoconfigur
IPv6 Address. . . . . . . . . . . : 2001:0:
rred)
Link-local IPv6 Address . . . . . : fe80::3005:
Default Gateway . . . . . . . . . : ::
NetBIOS over Tcpip. . . . . . . . : Disabled
and for reference, the vm is started with the following batch file/cmd line
cd "c:\program files (x86)\qemu"
qemu-system-
timsoft (tim-tree-of-life) wrote : | #6 |
I have also run the 64bit version of qemu with the slight modification of the batch/cmd line
cd "c:\program files\qemu"
qemu-system-
and get the same output both for the client(ip addr; ip route; ip tables -L -n )and host (ipconfig /all).
Stefan Hajnoczi (stefanha) wrote : | #7 |
On Tue, Jan 06, 2015 at 09:12:53PM -0000, timsoft wrote:
> output as requested from the guest:
> ip addr
> 1: lo: <LOOPBACK,
> 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,
> 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:
> 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:
> IPv4 Address. . . . . . . . . . . : 10.1.1.
> Subnet Mask . . . . . . . . . . . : 255.255.255.0
> Default Gateway . . . . . . . . . : 10.1.1.88
> DHCPv6 IAID . . . . . . . . . . . : 469958554
> DHCPv6 Client DUID. . . . . . . . : 00-01-00-
>
> DNS Servers . . . . . . . . . . . : 10.1.1.88
> NetBIOS over Tcpip. . . . . . . . : Enabled
So far, so good.
> Tunnel adapter isatap.
>
> Media State . . . . . . . . . . . : Media disconnected
> Connection-specific DNS Suffix . :
> Description . . . . . . . . . . . : Microsoft ISATAP Adapter
> Physical Address. . . . . . . . . : 00-00-00-
> DHCP Enabled. . . . . . . . . . . : No
> Autoconfiguration Enabled . . . . : Yes
>
> Tunnel adapter Teredo Tunneling ...
Stefan Hajnoczi (stefanha) wrote : | #8 |
On Tue, Jan 06, 2015 at 09:30:46PM -0000, timsoft wrote:
> I have also run the 64bit version of qemu with the slight modification
> of the batch/cmd line
>
> cd "c:\program files\qemu"
> qemu-system-
>
> and get the same output both for the client(ip addr; ip route; ip
> tables -L -n )and host (ipconfig /all).
Thanks for the information.
Since it's not clear whether the bridge configuration on the host is the
problem, I suggest removing the bridge:
Statically assign the tap interface on the host a local IP address like
192.168.5.1.
Statically assign 192.168.5.2 inside the guest.
See if guest and host can ping each other successfully.
This will show whether the problem is QEMU's tap networking or whether
the problem is the bridge configuration on the host.
Stefan
timsoft (tim-tree-of-life) wrote : | #9 |
I have tried what you suggested (breaking the bridge on the host, and giving the host tap 192.168.5.1 and the guest eth0 192.168.5.2
and tried pinging one from the other. I get 100% packet loss.
This points to QEMU's tap networking as far as I can see.
I have tried uninstalling the 64 bit version and installing the 32bit tap adapter (and bridging it) from openvpn 2.3.6-I601 but that didn't seem to make any difference.
I tried using a very old qemu (0.11.1) with qemu manager and the 32bit tap adapter and bridge set up (using the same disk image but specifying intel E1000 netcard for the vm) and that works.
so some time between 0.11.1 and 2.0 tap networking has got broken.
I can spend some more time trying stuff out if you have any suggestions. There must be some people actually using the windows host qemu and tap somewhere! :-)
(I don't have any problems running with a linux host and tap bridged network - well a few errors, but it (networking) seems to work anyway)
Tommy (dhsc19) wrote : | #10 |
I can concur that I am having the same problem on a Windows host.
neil prideaux (prideaux90) wrote : | #11 |
I also confirm the problem on Windows 7 host.
I tried the following over the past few nights:
Downloaded the OpenVPN tap 32 adapter. Installed it and gave it a different network address (192.168.200.10) to my normal LAN (192.168.1.10). Bridged the 2 connections, which gets me a new IP via DHCP at the bridge (192.168.1.101).
Got latest QEMU 2.2.0 for Windows from \lassauge.free.fr.
Got linux images from https:/
Debian guest boots up ok, but TAP networking is not happening, no matter what combinations or permutations i've tried to configure the guest net iface.
On the other hand, I obtained dsl-4.4.
After this attempt i've tried other versions of QEMU 1.6.0, and 1.1.1 with the same debian client still the same problem. i.e. boots up ok except for the TAP networking.
It is most likely a QEMU problem, but i am amazed at the number of blog posts of ppl claiming it to be working. It is unlikely they used a recent QEMU version.
James J Myers (myersjj) wrote : | #12 |
I'm having the same problem here on Windows 7 x64 host trying to run Raspbian.
Stefan Hajnoczi (stefanha) wrote : | #13 |
On Wed, Jan 07, 2015 at 04:09:55PM -0000, timsoft wrote:
> I have tried what you suggested (breaking the bridge on the host, and giving the host tap 192.168.5.1 and the guest eth0 192.168.5.2
> and tried pinging one from the other. I get 100% packet loss.
> This points to QEMU's tap networking as far as I can see.
> I have tried uninstalling the 64 bit version and installing the 32bit tap adapter (and bridging it) from openvpn 2.3.6-I601 but that didn't seem to make any difference.
You could put a fprintf(stderr, "Receiving a packet\n") into
net/tap-
packet\n") into tap_win32_write() if you think QEMU's Windows tap code
is broken.
Stefan
Thomas Huth (th-huth) wrote : | #14 |
Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
Changed in qemu: | |
status: | New → Incomplete |
timsoft (tim-tree-of-life) wrote : Re: [Bug 1404278] Re: tap connections not working on windows host | #15 |
i'll check with a more recent version and report back
On 22/05/2018 14:33, Thomas Huth wrote:
> Looking through old bug tickets... can you still reproduce this issue
> with the latest version of QEMU? Or could we close this ticket nowadays?
>
> ** Changed in: qemu
> Status: New => Incomplete
>
timsoft (tim-tree-of-life) wrote : | #16 |
it is working now. using the following config.
"c:\program files\qemu\
which I took from a linux qemu vm of mine, and just modified the bridge to point to tap (it didn't like -net bridge,br=br0 (where br0 was my windows bridge - I guess there is no bridge helper on windows qemu - so I changed it to -net tap,ifname=tap0 (which was already configured as part of the bridge)
I was able to ping the lan and also the wan (internet) so it looks ok now. This time i did specify a different virtual net card which may have made a difference, but if it works, that is the main thing.
Changed in qemu: | |
status: | Incomplete → Fix Released |
timsoft (tim-tree-of-life) wrote : | #17 |
addition to previous comment. it works with qemu-w64-
I haven't tested it with in between versions of qemu.
Thomas Huth (th-huth) wrote : | #18 |
ok, thanks for checking! So I'm closing this ticket now...
Thomas Huth (th-huth) wrote : | #19 |
... ah, well, never mind, just saw that you already closed it :-)
Jan Marti (wsertz3a) wrote : | #20 |
"it works with qemu-w64-
not really:
J:\Tools\
J:\Tools\
mu-4.4.34-jessie -m 512 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -no-reboot -m 256 -net nic -n
et tap,ifname=tap01
tap: Could not open 'tap01'
qemu-system-
Do i need to install some tap adapers on windows??
Jan Marti (wsertz3a) wrote : | #21 |
when i install tap driver from https:/
but on start i get an apipa address with that config:
qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-
why??
Jan Marti (wsertz3a) wrote : | #22 |
static ip does also not work, can't reach other machines in my own subnet:
qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-
???
Jan Marti (wsertz3a) wrote : | #23 |
problem solved! :-)
timsoft (tim-tree-of-life) wrote : | #24 |
hi jan, would you care to elaberate for the benefit of everyone "out there".
hgrbz (tf-x) wrote : | #25 |
Hi,
I want to run u-boot for x86_64 architecture in windows10 and I am using qemu-5.0.0, the latest version of qemu. The TAP adapter for Linux (host) worked successfully and I communicated between u-boot (guest) and Linux (host), but the result for Windows (host) failed.
I installed the Tap Network Adapter for windows and renamed it to "tap0" . when I ran the qemu with the following command without creating a bridge, u-boot was successfully initialized, but I cannot ping Windows (host).
qemu-system-
When I check (right click> status) for Tap0 it says No Network Connection.
I terminated qemu and connected tap0 to the internet using the config files I downloaded for OpenVPN.
When I checked tap0 again, I saw "Ipv4: Internet" but when I try to run qemu this way, I get an error like this.
tap: Could not open 'tap0'
qemu-system-
Varun Chitre (varun-chitre15) wrote : | #26 |
What was the fix that took place in the mainstream qemu? I'm facing the same issue on the latest Android Emulator (emulator: Android qemu version 30.3.5.0 (build_id 7033400) (CL:N/A)) on Windows 10.
TAP network gets attached just fine and shows us as eth1 on guest in ifconfig. But cannot ping the host. Tried removing the bridge i.e with just the standalone TAP adapter by assigning 192.168.5.2 to the host-side adapter and 192.168.5.3 to the guest-side - the guest cannot ping 192.168.5.2.
What was the actual fix? Maybe I can check if the fix got picked up or not on Google's emulator repo.
Stefan Hajnoczi (stefanha) wrote : | #27 |
Varun Chitre: I'm not sure the fix was identified, but this one stood out in the git log:
commit b73c1849148da12
Author: Andrew Baumann <email address hidden>
Date: Wed Nov 18 11:45:09 2015 -0800
tap-win32: disable broken async write path
same behaviour observed with qemu 2.2.0 32bit version for windows host