Using Fusion 3.1 on Snow Leopard (10.6.4), and have installed Ubuntu 8.0.4 as a guest OS. I need to use bridged networking instead of NAT so that I can get an IP address for the guest I can access from the host. This is on a Macbook Pro, so the bridged adapter is the AirPort (wireless) adapter.
The connectivity works, but every packet during a ping between host and guest (and presumably during other protocols as well) are duplicated. You can see the output of ping below. I've also looked to see if there are any duplicated MAC addresses or some other explanation, but can't find one (see output of ifconfig below).
I've searched the forums for whatever I can find on this issue, and have found many others with this problem but haven't found a solution. Does anyone know how to fix this? Fusion is superior to Parallels and VirtualBox in all other ways but this is a deal breaker for me unfortunately! Neither of those packages have this behavior using bridged networking on the AirPort adapter.
I'm really hoping there's some fix for this!
From host (OS X) to guest (Ubuntu 8.0.4):
$ ping 192.168.1.114
PING 192.168.1.114 (192.168.1.114): 56 data bytes
64 bytes from 192.168.1.114: icmp_seq=0 ttl=64 time=0.336 ms
64 bytes from 192.168.1.114: icmp_seq=0 ttl=64 time=3.339 ms (DUP!)
64 bytes from 192.168.1.114: icmp_seq=1 ttl=64 time=0.345 ms
64 bytes from 192.168.1.114: icmp_seq=1 ttl=64 time=2.242 ms (DUP!)
From guest (Ubuntu 8.0.4) to host (OS X):
$ ping 192.168.1.109
PING 192.168.1.109 (192.168.1.109) 56(84) bytes of data.
64 bytes from 192.168.1.109: icmp_seq=1 ttl=64 time=0.403 ms
64 bytes from 192.168.1.109: icmp_seq=1 ttl=63 time=3.51 ms (DUP!)
64 bytes from 192.168.1.109: icmp_seq=2 ttl=64 time=0.326 ms
64 bytes from 192.168.1.109: icmp_seq=2 ttl=63 time=4.25 ms (DUP!)
64 bytes from 192.168.1.109: icmp_seq=3 ttl=64 time=0.428 ms
64 bytes from 192.168.1.109: icmp_seq=3 ttl=63 time=0.548 ms (DUP!)
From host:
$ ifconfig
lo0: flags=8049 mtu 1500
ether 00:1c:42:00:00:09
inet 10.37.129.2 netmask 0xffffff00 broadcast 10.37.129.255
media: autoselect
status: active
From guest:
$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:0c:29:4a:2b:57
inet addr:192.168.1.114 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe4a:2b57/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3778 errors:3706 dropped:0 overruns:0 frame:0
TX packets:2660 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2762829 (2.6 MB) TX bytes:222752 (217.5 KB)
Interrupt:5 Base address:0x2024
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:80 errors:0 dropped:0 overruns:0 frame:0
TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4340 (4.2 KB) TX bytes:4340 (4.2 KB)
Using Fusion 3.1 on Snow Leopard (10.6.4), and have installed Ubuntu 8.0.4 as a guest OS. I need to use bridged networking instead of NAT so that I can get an IP address for the guest I can access from the host.
Your reason for using bridge is not accurate (as written). NAT networking allows you to ping and connect to all guest services from the host with no problems. Other machines on the network, however can't reach your guest without port forwarding.
The connectivity works, but every packet during a ping between host and guest (and presumably during other protocols as well) are duplicated. You can see the output of ping below.
You haven't really stated a problem, such as a performance issue or application problem. That is a large assumption you're making about other protocols than ICMP being duplicated. Do you have an actual issue or have you confirmed duplicated IP (TCP or UDP) traffic for other protocols?
I've searched the forums for whatever I can find on this issue, and have found many others with this problem but haven't found a solution. Does anyone know how to fix this? Fusion is superior to Parallels and VirtualBox in all other ways but this is a deal breaker for me unfortunately!
What you've presented hasn't illustrated exactly why this would be a "deal breaker". Your guest VMs aren't generating ICMP traffic normally until you run ping/traceroute commands. If you're not getting duplicated IP traffic and internet access is working, I don't see the justification for a fix. This is of course a differing opinion, but i would like to see more data other than ICMP ping.
I had tried NAT and couldn't find a way to get access to the guest via TCP. I'll look back into that. Although I can imagine a need for outside access to the guest at some point so it's not ideal.
As for whether this affects other protocols, I was assuming it would. However, based on your question I used Wireshark to analyze IP traffic during an SSH login and logout from the guest to the host, in both Parallels and Fusion, both over bridged networking. The results are that Parallels' traffic looks as expected, while Fusion's is suspect. There are tons of duplicate TCP packets, as well as a number that are listed as Out-Of-Order. I don't know that the latter is a problem as I presume they can get reordered on the other end, but since I've never seen this in such abundance before it gives me pause.
I'm developing software that relies on TCP streams back and forth which is why I care about this. I would have to do more work to confirm a performance deficit, but it seems reasonable to me to presume that so much extra traffic passing back and forth will have an effect. If I'm wrong in this presumption then let me know.
Here's the suspect packets:
26 13.126003 192.168.1.109 192.168.1.114 TCP [TCP Dup ACK 24#1] ssh > 55554 [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSV=607263428 TSER=1337925 32 13.131015 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 25#1] 55554 > ssh [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=1337927 TSER=607263428 SLE=0 SRE=1 33 13.131141 192.168.1.109 192.168.1.114 TCP [TCP Dup ACK 31#1] ssh > 55554 [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSV=607263428 TSER=1337925 42 13.147132 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 39#1] 55554 > ssh [ACK] Seq=833 Ack=22 Win=5856 Len=0 TSV=1337931 TSER=607263428 SLE=1 SRE=22 50 13.152899 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 47#1] 55554 > ssh [ACK] Seq=857 Ack=806 Win=7424 Len=0 TSV=1337932 TSER=607263428 SLE=22 SRE=806 55 13.158020 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 53#1] 55554 > ssh [ACK] Seq=857 Ack=958 Win=8992 Len=0 TSV=1337933 TSER=607263428 SLE=806 SRE=958 58 13.160393 192.168.1.109 192.168.1.114 TCP [TCP Dup ACK 57#1] ssh > 55554 [ACK] Seq=958 Ack=1001 Win=524280 Len=0 TSV=607263428 TSER=1337933 64 13.172263 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 62#1] 55554 > ssh [ACK] Seq=1017 Ack=1678 Win=10560 Len=0 TSV=1337937 TSER=607263428 SLE=958 SRE=1678 72 13.173604 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 69#1] 55554 > ssh [ACK] Seq=1129 Ack=1726 Win=10560 Len=0 TSV=1337937 TSER=607263428 74 13.173970 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 69#2] 55554 > ssh [ACK] Seq=1129 Ack=1726 Win=10560 Len=0 TSV=1337937 TSER=607263428 76 13.174282 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 69#3] 55554 > ssh [ACK] Seq=1129 Ack=1726 Win=10560 Len=0 TSV=1337937 TSER=607263428 SLE=1678 SRE=1726 82 13.174989 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 79#1] 55554 > ssh [ACK] Seq=1225 Ack=1790 Win=10560 Len=0 TSV=1337938 TSER=607263428 85 13.176632 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 79#2] 55554 > ssh [ACK] Seq=1225 Ack=1790 Win=10560 Len=0 TSV=1337938 TSER=607263428 SLE=1726 SRE=1790 90 13.191083 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 88#1] 55554 > ssh [ACK] Seq=1225 Ack=1854 Win=10560 Len=0 TSV=1337942 TSER=607263428 SLE=1790 SRE=1854 94 15.099880 192.168.1.109 192.168.1.114 TCP [TCP Dup ACK 93#1] ssh > 55554 [ACK] Seq=1854 Ack=1305 Win=524280 Len=0 TSV=607263447 TSER=1338418 103 15.113515 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 100#1] 55554 > ssh [ACK] Seq=1449 Ack=1934 Win=10560 Len=0 TSV=1338422 TSER=607263448 SLE=1854 SRE=1902 105 15.113874 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 100#2] 55554 > ssh [ACK] Seq=1449 Ack=1934 Win=10560 Len=0 TSV=1338422 TSER=607263448 107 15.114698 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 100#3] 55554 > ssh [ACK] Seq=1449 Ack=1934 Win=10560 Len=0 TSV=1338423 TSER=607263448 SLE=1902 SRE=1934 114 15.137268 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 111#1] 55554 > ssh [ACK] Seq=1897 Ack=1982 Win=10560 Len=0 TSV=1338428 TSER=607263448 SLE=1934 SRE=1982 121 15.144265 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 119#1] 55554 > ssh [ACK] Seq=1897 Ack=2126 Win=10560 Len=0 TSV=1338430 TSER=607263448 SLE=1982 SRE=2030 123 15.145207 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 119#2] 55554 > ssh [ACK] Seq=1897 Ack=2126 Win=10560 Len=0 TSV=1338430 TSER=607263448 SLE=2030 SRE=2126 127 15.153839 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 125#1] 55554 > ssh [ACK] Seq=1897 Ack=2190 Win=10560 Len=0 TSV=1338432 TSER=607263448 SLE=2126 SRE=2190 133 15.708280 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 131#1] 55554 > ssh [ACK] Seq=1945 Ack=2238 Win=10560 Len=0 TSV=1338571 TSER=607263454 135 15.708365 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 131#2] 55554 > ssh [ACK] Seq=1945 Ack=2238 Win=10560 Len=0 TSV=1338571 TSER=607263454 SLE=2190 SRE=2238 141 15.850213 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 139#1] 55554 > ssh [ACK] Seq=1993 Ack=2286 Win=10560 Len=0 TSV=1338606 TSER=607263455 143 15.851055 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 139#2] 55554 > ssh [ACK] Seq=1993 Ack=2286 Win=10560 Len=0 TSV=1338607 TSER=607263455 SLE=2238 SRE=2286 149 15.922409 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 147#1] 55554 > ssh [ACK] Seq=2041 Ack=2334 Win=10560 Len=0 TSV=1338625 TSER=607263456 151 15.922528 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 147#2] 55554 > ssh [ACK] Seq=2041 Ack=2334 Win=10560 Len=0 TSV=1338625 TSER=607263456 SLE=2286 SRE=2334 157 16.010088 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 155#1] 55554 > ssh [ACK] Seq=2089 Ack=2382 Win=10560 Len=0 TSV=1338646 TSER=607263457 159 16.010088 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 155#2] 55554 > ssh [ACK] Seq=2089 Ack=2382 Win=10560 Len=0 TSV=1338646 TSER=607263457 SLE=2334 SRE=2382 167 16.098557 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 165#1] 55554 > ssh [ACK] Seq=2137 Ack=2478 Win=10560 Len=0 TSV=1338669 TSER=607263457 169 16.098874 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 165#2] 55554 > ssh [ACK] Seq=2137 Ack=2478 Win=10560 Len=0 TSV=1338669 TSER=607263457 SLE=2382 SRE=2430 171 16.099192 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 165#3] 55554 > ssh [ACK] Seq=2137 Ack=2478 Win=10560 Len=0 TSV=1338669 TSER=607263457 SLE=2430 SRE=2478 179 16.100651 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 176#1] 55554 > ssh [ACK] Seq=2170 Ack=2606 Win=12128 Len=0 TSV=1338669 TSER=607263457 185 16.107518 192.168.1.114 192.168.1.109 TCP [TCP Dup ACK 183#1] 55554 > ssh [ACK] Seq=2170 Ack=2607 Win=12128 Len=0 TSV=1338671 TSER=607263458 41 13.147103 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] ssh > 55554 [PSH, ACK] Seq=1 Ack=1 Win=524280 Len=21 TSV=607263428 TSER=1337927[Malformed Packet] 49 13.152867 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Server: Key Exchange Init 54 13.157999 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=152 63 13.172212 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=720 75 13.174264 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=48 84 13.176605 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=64 89 13.191067 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=64 102 15.113493 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=48 106 15.114680 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=32 113 15.137253 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=48 120 15.144253 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=48 122 15.145186 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=96 126 15.153823 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=64 142 15.851042 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=48 150 15.922515 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=48 158 16.010088 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=48 168 16.098858 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=48 170 16.099173 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=48 178 16.100630 192.168.1.109 192.168.1.114 SSHv2 [TCP Out-Of-Order] Encrypted response packet len=128
I went ahead and sniffed the traffic while using NAT and don't see any problem packets. I also can ssh in to the guest from the host as you said. I don't have everything setup on the guest yet (so I can't test it), but will I be able to telnet in over a specific port using NAT as well?
I went ahead and sniffed the traffic while using NAT and don't see any problem packets. I also can ssh in to the guest from the host as you said. I don't have everything setup on the guest yet (so I can't test it), but will I be able to telnet in over a specific port using NAT as well?
Yes, every guest port is available to the host, so you can run sshd or httpd on different ports and access them from OS X.
If you want to keep NAT and allow other machines on your network to ssh into your VMs, turn off the corresponding services in OS X and modify /Library/Application Support/VMware Fusion/vmnet8/nat.config picking specific TCP or UDP protocols to port forward, e.g. 22 = guestIP:guestPort. You can also set up of form of port address translation, where 8022 in OS X maps to 22 on your guest for ssh, 8080 for guest port 80 and so on. There was a bug introduced in 3.0 where nat.conf would get overwritten by Fusion, but hopefully that's fixed in 3.1.
is there any way to contact support and ask them if they've got a fix in the works for the duplicates? i tried online but it said i had to have a support contract or some such thing.
According to VMware Support Options, Fusion 3.x has 18 months of complimentary support via phone/web with responses via email and target response time of 24 hours from time of submission.
A host-only network is reliable without duplicates if you shutdown your VM and add a secondary network adapter in Virtual Machine > Settings > + drop-down menu > Add Network. Boot the VM and use ifconfig get to your guest's new secondary IP address. Once you have that you can ping, ssh, http, etc into your guest from the host, with no duplicates. Your bridged traffic from other network machines will still be able to reach your VM without duplicates on the primary interface. I think duplicates only affects bridged traffic from the OS X host to your guest, a host-only adapter solves that issue.
edit: Tested a secondary host-only adapter in Ubuntu 10.4 and pings are not duplicated from OS X:
fusion:~ rcardona$ ping 192.168.167.128 PING 192.168.167.128 (192.168.167.128): 56 data bytes 64 bytes from 192.168.167.128: icmp_seq=0 ttl=64 time=0.304 ms 64 bytes from 192.168.167.128: icmp_seq=1 ttl=64 time=0.317 ms 64 bytes from 192.168.167.128: icmp_seq=2 ttl=64 time=0.373 ms 64 bytes from 192.168.167.128: icmp_seq=3 ttl=64 time=0.338 ms 64 bytes from 192.168.167.128: icmp_seq=4 ttl=64 time=0.334 ms --- 192.168.167.128 ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.304/0.333/0.373/0.023 ms