VMware Communities
mixwhit
Contributor
Contributor

Duplicate pings between guest and host when using bridged networking -- any fix??

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)

Tags (1)
0 Kudos
7 Replies
rcardona2k
Immortal
Immortal

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.

0 Kudos
mixwhit
Contributor
Contributor

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

0 Kudos
mixwhit
Contributor
Contributor

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?

0 Kudos
rcardona2k
Immortal
Immortal

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.

0 Kudos
mixwhit
Contributor
Contributor

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.

0 Kudos
rcardona2k
Immortal
Immortal

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.

rcardona2k
Immortal
Immortal

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

0 Kudos