Duplicate packets with ping on guest OS(Linux)

Duplicate packets with ping on guest OS(Linux)

Hi,

I am getting lot of duplicate packets when i ping to an IP (router, host system or an internet server)  from my guest OS.

Any pointers with this regard would be greatly helpful.

I have the following configuration:

VMware Workstation 6.0.0 build-45731

Host OS: Windows XP SP2 (32bit)
Guest OS: Fedora Core 6 - 32bit (Zod - Kernel ver: 2.6.18-1.2798.fc6)

I have bridged VMnet0 to the 'Wireless Connection' on the Host OS.

\## Host OS ##

\## ipconfig /all ##

Windows IP Configuration

Host Name . . . . . . . . . . . . : homePC
Primary Dns Suffix  . . . . . . . :
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : Yes
WINS Proxy Enabled. . . . . . . . : Yes
DNS Suffix Search List. . . . . . : xyz.edu
xyz.edu

Ethernet adapter VMware Network Adapter VMnet8:

Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet8
Physical Address. . . . . . . . . : 00-50-56-C0-00-08
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.93.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter VMware Network Adapter VMnet1:

Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet1
Physical Address. . . . . . . . . : 00-50-56-C0-00-01
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.157.1
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :

Ethernet adapter Wireless Network Connection:

Connection-specific DNS Suffix  . : xyz.edu
Description . . . . . . . . . . . : Intel(R) PRO/Wireless LAN 2100 3B Mini PCI Adapter
Physical Address. . . . . . . . . : 00-0C-F1-3C-99-C7
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.15.101
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.15.1
DHCP Server . . . . . . . . . . . : 192.168.15.1
DNS Servers . . . . . . . . . . . : 192.168.15.1
Lease Obtained. . . . . . . . . . : Wednesday, September 12, 2007 4:19:54 PM
Lease Expires . . . . . . . . . . : Thursday, September 13, 2007 4:19:54 PM

\## VMX file: ##


config.version = "8"
virtualHW.version = "6"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
memsize = "400"
ide0:0.present = "TRUE"
ide0:0.fileName = "Other Linux 2.6.x kernel.vmdk"
ide0:0.deviceType = "rawDisk"
ide1:0.present = "TRUE"
ide1:0.fileName = "auto detect"
ide1:0.deviceType = "cdrom-raw"
floppy0.autodetect = "TRUE"
ethernet0.present = "TRUE"
ethernet0.wakeOnPcktRcv = "FALSE"
usb.present = "TRUE"
ehci.present = "TRUE"
sound.present = "TRUE"
sound.fileName = "-1"
sound.autodetect = "TRUE"
svga.autodetect = "TRUE"
pciBridge0.present = "TRUE"
mks.keyboardFilter = "allow"
displayName = "FedoraCore6"
guestOS = "other26xlinux"
nvram = "Other Linux 2.6.x kernel.nvram"
deploymentPlatform = "windows"
virtualHW.productCompatibility = "hosted"
tools.upgrade.policy = "useGlobal"

ide1:0.autodetect = "TRUE"
floppy0.startConnected = "FALSE"
floppy0.fileName = "A:"

isolation.tools.hgfs.disable = "TRUE"

ide1:0.startConnected = "TRUE"
ethernet0.addressType = "generated"
uuid.location = "56 4d 5e 41 94 bb 63 f6-84 09 ef 88 ec fe ce cd"
uuid.bios = "56 4d 5e 41 94 bb 63 f6-84 09 ef 88 ec fe ce cd"
ide0:0.redo = ""
pciBridge0.pciSlotNumber = "17"
scsi0.pciSlotNumber = "16"
ethernet0.pciSlotNumber = "32"
sound.pciSlotNumber = "33"
ehci.pciSlotNumber = "34"
ethernet0.generatedAddress = "00:0c:29:fe:ce:cd"
ethernet0.generatedAddressOffset = "0"
tools.syncTime = "FALSE"

checkpoint.vmState = ""


\## Guest OS ##

\[root@localhost ~]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:0C:29:FE:CE:CD 
inet addr:192.168.15.103  Bcast:192.168.15.255  Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fefe:cecd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:324 errors:0 dropped:0 overruns:0 frame:0
TX packets:80 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:43943 (42.9 KiB)  TX bytes:14055 (13.7 KiB)
Interrupt:169 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:3510 errors:0 dropped:0 overruns:0 frame:0
TX packets:3510 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:5844724 (5.5 MiB)  TX bytes:5844724 (5.5 MiB)

sit0      Link encap:IPv6-in-IPv4 
NOARP  MTU:1480  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)


\[root@localhost ~]# ping www.yahoo.com
PING www.yahoo.com (69.147.114.210) 56(84) bytes of data.
64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=56 time=50.7 ms
64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=55 time=56.6 ms (DUP!)
64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=54 time=58.6 ms (DUP!)
64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=53 time=68.6 ms (DUP!)
64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=52 time=68.6 ms (DUP!)
64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=51 time=80.6 ms (DUP!)
64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=50 time=186 ms (DUP!)
64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=49 time=355 ms (DUP!)
64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=48 time=504 ms (DUP!)

\--- www.yahoo.com ping statistics ---
1 packets transmitted, 1 received, +8 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 50.705/159.022/504.678/154.117 ms

----


That happens
\- if you ping a broadcast address, because you send one ping and get many answers back.
\- if two or more systems have the same IP and both send an answer back.
\- if your NIC is in promiscious mode and you have a not so smart switch  (or hub) which sends the ping also back to the pinging system.

AWo

Message was edited by:
AWo


The problem I later figured out was because i have bridged VMnet0 to the  Wireless Connection on the Host OS. I believe that caused the problem  (may be  because it had a WEP key).

Later I bridged VMnet0 to the wired connection. It works find now.

Thank you for all who responded.


Hi! There is a solution to this problem? I have the same problem with a  vmnet interface bridged with a wireless Intel ipw3945 without any  protection to the wireless network (no wep, no mac control).

Thanks,
Simone


I'm bridging via Intel 3945ABG Wireless NIC, and got dup ping response.

after looking at the traffic captured by WireShark, I see the following things (with MAC OUI):

(1) 192.168.0.21 IntelCor => 192.168.0.1 D-Link ICMP Echo (ping) request (seq = 1)


(2) 192.168.0.1 D-Link => 192.168.0.121 IntelCor ICMP Echo (ping) reply (seq = 1)


(3) 192.168.0.1 IntelCor => 192.168.0.121 IntelCor ICMP Echo (ping) reply  (seq = 1)


it seems to be a problem in Wireless NIC driver (the third packet has the same Src MAC and Dst MAC).


sorry, seems not the problem of Intel Wireless NIC.

The expected behavior is:

(1) 192.168.0.21 VMware => 192.168.0.1 D-Link ICMP Echo (ping) request (seq = 1)

(2) 192.168.0.1 D-Link => 192.168.0.121 InterCor ICMP Echo (ping) reply (seq = 1)

(3) 192.168.0.1 InterCor => 192.168.0.121 VMware ICMP Echo (ping) reply  (seq = 1)

The following links are talking about the similar problem:

http://communities.vmware.com/thread/120356

http://communities.vmware.com/thread/138858

http://communities.vmware.com/thread/176249

http://www.linuxfans.org/bbs/thread-52385-1-200.html

I'll update this thread as I got something new.


I have been having the same problem.  I am using VMWare player 3.1.3
build-324285 running a Ubuntu client on a Windows 7 host.  I have tried
several means of trying to determine what exactly the problem is and
have found this:

Environment:

1 - Ubuntu guest running in the above configuration (192.168.0.105), called server A, MAC address 40:00:00:00:00:01
1 - Physical Ubuntu server (192.168.0.107), called server B , MAC address 00:02:b3:f0:b7:51
1 - Physical Windows 7 VMWare Player host machine, MAC address  90:e6:ba:80:07:f4
Both physcal servers are on the same physical switch and VMWare is set up for bridging.

Procedure:

Initiate one ping packet from  server A (example: ping -c 1 192.168.0.107) to server B

Capture all ICMP traffic on the ethernet interface using tcpdump (example: tcpdump -w capture.cap icmp)

Results from Wireshark analysis:

TimeProt.SourceSrc MACDestinationDst MACInfo
0.00000ICMP192.168.0.10590:e6:ba:80:07:f4192.168.0.10700:02:b3:f0:b7:51Echo (ping) request
0.00002ICMP192.168.0.10700:02:b3:f0:b7:51192.168.0.10540:00:00:00:00:01Echo (ping) reply
0.00002ICMP192.168.0.10540:00:00:00:00:01192.168.0.10700:02:b3:f0:b7:51Echo (ping) request
0.00003ICMP192.168.0.10700:02:b3:f0:b7:51192.168.0.10540:00:00:00:00:01Echo (ping) reply
0.00019ICMP192.168.0.10290:e6:ba:80:07:f4192.168.0.10700:02:b3:f0:b7:51Redirect (Redirect for network)


    • I did validate that this pattern continues if two or more consecutive pings are initiated as well.
    • In the 1st packet the Source MAC address should be 40:00:00:00:00:01*Analysis:*


It appears that somehow the host machine is duplicating the ping request
thereby doubling the amount of ping replies.  In addition it is causing
the host to send  an ICMP redirect further polluting the network with
unnecessary traffic.  Somewhere the packet is getting duplicated, I
believe the most likely candidate is the windows IP stack (or maybe
within the routing engine) or a bug in the VMWare driver.  It is
interesting to note that the incorrect packet is sent first.

The redirect seems to be an effect of the duplicate packet (the 1st ping
request) and the fact that it is not originating from the appropriate
MAC address associated to 192.168.0.105 in the arp table on the vmware
host thereby looking like an inefficiently routed packet.

Any thoughts as to how to get Windows/VMWare to stop duplicating the
packet?   The redirect is a symptom, not the cause.  I have disabled
redirects in the registry and filtered them out with firewall rules, but
the best that is achieved is that the redirect packet is eliminated. 
The duplicate packets still occur.


how many physical nics does your host have ?
how did you configure the vmnet-bridge ?
did you disable  automatic-bridging  ?

_________________________

VMX-parameters- WS FAQ - MOAcd - VMDK-Handbook


Each device has one physical NIC.

Bridging is setup however the default settings are set up.  The VMWare  player doesn't give you too many options for configuration.  Is there a  file that contains settings you can manually modify?


I see - looks you have not yet extracted the vmnetcfg.exe tool.

before you have not disabled automatic-bridging troubleshooting bridge problems is moot

_________________________

VMX-parameters- WS FAQ - MOAcd - VMDK-Handbook


Ok, I found that you can check the configuration of the vmnet0 bridging  interface with a utility called vmnetcfg.  I found that my installation  did not have the executable.  I found the procedure below to add the  command.

To extract vmnetcfg.exe from the installer do the following:

1. Run the installer with /e option. For example:
VMware-player-3.0.0-197124.exe /e .\extract
Contents will be extracted to “extract” folder.
2. Open “network.cab” and copy vmnetcfg.exe to your installation folder,
typically “C:\Program Files\VMware\VMware Player\”.

After I extracted the executable I ran it and manually bound only the  physical adapter to vmnet0.  Unfortunately this did not change anything.   I also disabled vmnet1 and vmnet8.  This also did not affect the  behaviour.

Any other thoughts?


Looks like a lot of good info in those links.  I'll definately be spending some time looking through them.  Thanks!


FYI My .vmx file:

#!/usr/bin/vmware
.encoding = "windows-1252"
tools.statusMsgs.disable = "TRUE"
virtualHW.version = "4"
ide0:0.autodetect = "TRUE"
tools.syncTime = "TRUE"
nvram = "appliance.nvram"
ide0:0.present = "TRUE"
config.version = "8"
ide0:0.fileName = "auto detect"
ide0:0.startConnected = "FALSE"
ide0:0.deviceType = "cdrom-raw"
MemAllowAutoScaleDown = "FALSE"
tools.remindInstall = "FALSE"
uuid.action = "create"
displayName = "OpenVPN AS - config 2"
guestOS = "ubuntu"
vix.inGuest.enable="TRUE"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
scsi0:0.fileName = "system.vmdk"
scsi0:0.present = "TRUE"
memsize = "512"
ethernet0.present = "TRUE"
ethernet0.addressType = "generated"
ethernet0.connectionType = "bridged"

scsi0:0.redo = ""
ethernet0.generatedAddress = "00:0c:29:d3:b1:59"
uuid.location = "56 4d 99 eb 12 62 71 9a-8d 47 bb d1 bd d3 b1 59"
uuid.bios = "56 4d 99 eb 12 62 71 9a-8d 47 bb d1 bd d3 b1 59"
priority.grabbed = "normal"
priority.ungrabbed = "normal"
ethernet0.generatedAddressOffset = "0"
extendedConfigFile = "OpenVPN-AS-Appliance.vmxf"
virtualHW.productCompatibility = "hosted"
cleanShutdown = "FALSE"
replay.supported = "FALSE"
replay.filename = ""
vmotion.checkpointFBSize = "16777216"
sound.present = "FALSE"
usb.present = "FALSE"
floppy0.present = "FALSE"
checkpoint.vmState = "OpenVPN-AS-Appliance.vmss"
ethernet0.linkStatePropagation.enable = "TRUE"


installation of WS 7.1.3 on win7 can go wrong in many ways

please walk through my notes - http://faq.sanbarrow.com/index.php?solution_id=1113

there I have a section "how to verify correct installation of drivers" also check the services

I just see you use virtual hardware type 4 - that may also play into this game - do you need such old version ???

_________________________

VMX-parameters- WS FAQ - MOAcd - VMDK-Handbook


Ok, I have validated the registry keys in your document and I do only  have the test key with the dword value of 0.  So something apparently  did not setup correctly.

I am not sure what determines the Hardware level, is it just safe to change it to another number?  If so, what do you recommend?

I'll try your procedure to do a clean install and let you know what happens.

Thanks for your help.


Oops, I didn't expand under adapters, I do indeed have adapters defined.  Here is what is in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VMnetBridge\Parameters\Adapters\{595DC473-40E3-...
"VMnet"=dword:00000000

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VMnetBridge\Parameters\Adapters\{DAB98AAE-5B0F-...
"VMnet"=dword:ffffffff


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VMnetBridge\Parameters\Adapters\{F9791023-4378-...
"VMnet"=dword:ffffffff


After seeing this I was poking around in the other parameters and found  these multi string entries.  The Route string is what caught my eye:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VMnetBridge\Linkage
"Bind"=hex(7):5c,00,44,00,65,00,76,00,69,00,63,00,65,00,5c,00,7b,00,35,00,39,\
00,35,00,44,00,43,00,34,00,37,00,33,00,2d,00,34,00,30,00,45,00,33,00,2d,00,\
34,00,34,00,30,00,31,00,2d,00,41,00,34,00,39,00,31,00,2d,00,35,00,37,00,33,\
00,46,00,35,00,39,00,33,00,30,00,31,00,38,00,38,00,35,00,7d,00,00,00,5c,00,\
44,00,65,00,76,00,69,00,63,00,65,00,5c,00,7b,00,46,00,39,00,37,00,39,00,31,\
00,30,00,32,00,33,00,2d,00,34,00,33,00,37,00,38,00,2d,00,34,00,45,00,32,00,\
46,00,2d,00,41,00,35,00,34,00,31,00,2d,00,37,00,43,00,32,00,35,00,45,00,39,\
00,37,00,37,00,39,00,33,00,32,00,43,00,7d,00,00,00,5c,00,44,00,65,00,76,00,\
69,00,63,00,65,00,5c,00,7b,00,44,00,41,00,42,00,39,00,38,00,41,00,41,00,45,\
00,2d,00,35,00,42,00,30,00,46,00,2d,00,34,00,44,00,31,00,33,00,2d,00,38,00,\
30,00,36,00,31,00,2d,00,37,00,38,00,46,00,33,00,41,00,32,00,32,00,38,00,37,\
00,39,00,39,00,46,00,7d,00,00,00,00,00
"Route"=hex(7):22,00,7b,00,35,00,39,00,35,00,44,00,43,00,34,00,37,00,33,00,2d,\
00,34,00,30,00,45,00,33,00,2d,00,34,00,34,00,30,00,31,00,2d,00,41,00,34,00,\
39,00,31,00,2d,00,35,00,37,00,33,00,46,00,35,00,39,00,33,00,30,00,31,00,38,\
00,38,00,35,00,7d,00,22,00,00,00,22,00,7b,00,46,00,39,00,37,00,39,00,31,00,\
30,00,32,00,33,00,2d,00,34,00,33,00,37,00,38,00,2d,00,34,00,45,00,32,00,46,\
00,2d,00,41,00,35,00,34,00,31,00,2d,00,37,00,43,00,32,00,35,00,45,00,39,00,\
37,00,37,00,39,00,33,00,32,00,43,00,7d,00,22,00,00,00,22,00,7b,00,44,00,41,\
00,42,00,39,00,38,00,41,00,41,00,45,00,2d,00,35,00,42,00,30,00,46,00,2d,00,\
34,00,44,00,31,00,33,00,2d,00,38,00,30,00,36,00,31,00,2d,00,37,00,38,00,46,\
00,33,00,41,00,32,00,32,00,38,00,37,00,39,00,39,00,46,00,7d,00,22,00,00,00,\
00,00
"Export"=hex(7):5c,00,44,00,65,00,76,00,69,00,63,00,65,00,5c,00,56,00,4d,00,6e,\
00,65,00,74,00,42,00,72,00,69,00,64,00,67,00,65,00,5f,00,7b,00,35,00,39,00,\
35,00,44,00,43,00,34,00,37,00,33,00,2d,00,34,00,30,00,45,00,33,00,2d,00,34,\
00,34,00,30,00,31,00,2d,00,41,00,34,00,39,00,31,00,2d,00,35,00,37,00,33,00,\
46,00,35,00,39,00,33,00,30,00,31,00,38,00,38,00,35,00,7d,00,00,00,5c,00,44,\
00,65,00,76,00,69,00,63,00,65,00,5c,00,56,00,4d,00,6e,00,65,00,74,00,42,00,\
72,00,69,00,64,00,67,00,65,00,5f,00,7b,00,46,00,39,00,37,00,39,00,31,00,30,\
00,32,00,33,00,2d,00,34,00,33,00,37,00,38,00,2d,00,34,00,45,00,32,00,46,00,\
2d,00,41,00,35,00,34,00,31,00,2d,00,37,00,43,00,32,00,35,00,45,00,39,00,37,\
00,37,00,39,00,33,00,32,00,43,00,7d,00,00,00,5c,00,44,00,65,00,76,00,69,00,\
63,00,65,00,5c,00,56,00,4d,00,6e,00,65,00,74,00,42,00,72,00,69,00,64,00,67,\
00,65,00,5f,00,7b,00,44,00,41,00,42,00,39,00,38,00,41,00,41,00,45,00,2d,00,\
35,00,42,00,30,00,46,00,2d,00,34,00,44,00,31,00,33,00,2d,00,38,00,30,00,36,\
00,31,00,2d,00,37,00,38,00,46,00,33,00,41,00,32,00,32,00,38,00,37,00,39,00,\
39,00,46,00,7d,00,00,00,00,00


Translated to ascii each multi string is:


"{595DC473-40E3-4401-A491-573F59301885}"
"{F9791023-4378-4E2F-A541-7C25E977932C}"
"{DAB98AAE-5B0F-4D13-8061-78F3A228799F}"


This made me notice that the bridged interface was being routed.  I  removed the   "{595DC473-40E3-4401-A491-573F59301885}" entry and voila,  no more duplicate packets.


Thank you ever so much for your help.  Without it I would never have made it this far.


This would appear to be a bug with VMWare, what is the best way to  report something like this without having a service contract?  From  other posts I've seen I'm not the only one that has had this issue.

This document was generated from the following thread: Duplicate packets with ping on guest OS(Linux)

Version history
Revision #:
1 of 1
Last update:
‎12-02-2010 08:37 PM
Updated by: