path: root/results/classifier/zero-shot/118/all/1404278

register: 0.978
debug: 0.978
performance: 0.973
assembly: 0.970
graphic: 0.969
semantic: 0.968
permissions: 0.964
peripherals: 0.962
device: 0.962
PID: 0.959
arm: 0.957
network: 0.956
virtual: 0.955
architecture: 0.955
user-level: 0.951
hypervisor: 0.941
mistranslation: 0.940
vnc: 0.938
files: 0.930
socket: 0.914
VMM: 0.914
ppc: 0.910
risc-v: 0.909
boot: 0.904
TCG: 0.900
x86: 0.896
KVM: 0.885
kernel: 0.872
i386: 0.821

tap connections not working on windows host

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.

same behaviour observed with qemu 2.2.0 32bit version for windows host

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-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.

Please try tcpdump or Wireshark on guest and host to check whether ping
works in either direction.

Stefan


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.

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


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 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

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

and for reference, the vm is started with the following batch file/cmd line

cd "c:\program files (x86)\qemu"
qemu-system-x86_64w.exe -m 512 -net nic -net tap,ifname=tap01 -hda "c:\\data\\images\\test.img"



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-x86_64w.exe -m 512 -net nic -net tap,ifname=tap01 -hda "c:\\data\\images\\test.img"

 and get the same output both for the client(ip addr; ip route; ip tables -L -n  )and host (ipconfig /all).

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


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-x86_64w.exe -m 512 -net nic -net tap,ifname=tap01 -hda "c:\\data\\images\\test.img"
> 
>  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


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)

I can concur that I am having the same problem on a Windows host.

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://people.debian.org/~aurel32/qemu/armel/ and used the command as per the instructions there. Further added the -net tap swithches to the cmd line, similar to above.

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.10-embedded.zip  which comes with its own QEMU from http://ftp.heanet.ie/mirrors/damnsmalllinux.org/current/. After changing the command line to start QEMU with the -tap switch, and configuring dsl for dhcp, i was up and running immediately (automagically obtained its own ip as my host network as 192.168.1.102, same gateway as host network, pings ok in either direction, even pings google.com). This proves the tap adapter and bridge is configured correctly on the host side, and the supplied QEMU version works ok - can't tell exactly which QEMU version but it is circa 2006.

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.

I'm having the same problem here on Windows 7 x64 host trying to run Raspbian.

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-win32.c:tap_win32_send() as well as fprintf(stderr, "Sending a
packet\n") into tap_win32_write() if you think QEMU's Windows tap code
is broken.

Stefan


Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?

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
>



it is working now. using the following config.
"c:\program files\qemu\qemu-system-i386.exe" -cpu qemu32 -m 3G -drive file="c:\\data\\images\\slack14.2_32bit_base.qcow2",format=qcow2 -cdrom "c:\\data\\images\\slackware-14.2-install-dvd.iso" -boot c -net nic,macaddr=02:00:00:11:11:14,model=i82551 -net tap,ifname=tap0 -k en-gb -display vnc=:2 -monitor telnet:localhost:7101,server,nowait,nodelay
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.

addition to previous comment. it works with qemu-w64-setup-20180519.exe
I haven't tested it with in between versions of qemu.

ok, thanks for checking! So I'm closing this ticket now...

... ah, well, never mind, just saw that you already closed it :-)

"it works with qemu-w64-setup-20180519.exe"

not really:

J:\Tools\qemu>.\run.bat
J:\Tools\qemu>qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qe
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-arm.exe: Device 'tap' could not be initialized


Do i need to install some tap adapers on windows??

when i install tap driver from https://openvpn.net/index.php/open-source/downloads.html im able to start with tap01 (when i rename the tap interface to "tap01"..)

but on start i get an apipa address with that config:

qemu-system-arm.exe -M versatilepb -cpu arm1176 -hda 2018-09-03_stretch_inkl_phalcon.img -kernel kernel-qemu-4.4.34-jessie -m 512 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -no-reboot -m 256 -net nic -net tap,ifname=tap01


why??

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-03_stretch_inkl_phalcon.img -kernel kernel-qemu-4.4.34-jessie -m 512 -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw ip=192.168.80.252::192.168.80.1:255.255.255.0::eth0:none" -no-reboot -m 256 -net nic -net tap,ifname=tap01

???

problem solved! :-)



hi jan, would you care to elaberate for the benefit of everyone "out there".

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-x86_64.exe -bios u-boot.rom -nographic -device  e1000,netdev=mynet0 -netdev tap,id=mynet0,ifname=tap0

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-x86_64.exe: Device 'tap' could not be initialized




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.

Varun Chitre: I'm not sure the fix was identified, but this one stood out in the git log:

commit b73c1849148da1229a3c3b336311a8194970b35f
Author: Andrew Baumann <email address hidden>
Date:   Wed Nov 18 11:45:09 2015 -0800

    tap-win32: disable broken async write path