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 => 192.168.0.1 ICMP Echo (ping) request (seq = 1)
(2) 192.168.0.1 => 192.168.0.121 ICMP Echo (ping) reply (seq = 1)
(3) 192.168.0.1 => 192.168.0.121 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
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:
Time | Prot. | Source | Src MAC | Destination | Dst MAC | Info |
0.00000 | ICMP | 192.168.0.105 | 90:e6:ba:80:07:f4 | 192.168.0.107 | 00:02:b3:f0:b7:51 | Echo (ping) request |
0.00002 | ICMP | 192.168.0.107 | 00:02:b3:f0:b7:51 | 192.168.0.105 | 40:00:00:00:00:01 | Echo (ping) reply |
0.00002 | ICMP | 192.168.0.105 | 40:00:00:00:00:01 | 192.168.0.107 | 00:02:b3:f0:b7:51 | Echo (ping) request |
0.00003 | ICMP | 192.168.0.107 | 00:02:b3:f0:b7:51 | 192.168.0.105 | 40:00:00:00:00:01 | Echo (ping) reply |
0.00019 | ICMP | 192.168.0.102 | 90:e6:ba:80:07:f4 | 192.168.0.107 | 00:02:b3:f0:b7:51 | Redirect (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:01Analysis:
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|http://sanbarrow.com/moa241.html] - 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|http://sanbarrow.com/moa241.html] - 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|http://sanbarrow.com/moa241.html] - 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:
"VMnet"=dword:00000000
"VMnet"=dword:ffffffff
"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:
"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.
I was annoyed by these (DUP!) pings, googling found that the culprit on a Windows 7 host is a service called "Routing and Remote Access". Stopping and disabling it immediately ceased duped pings on all running machines.
I was afraid it would affect Remote Desktop (RDP mstsc.exe) connectivity but it didn't, host machine is still well available over RDP.
I was trying juggling vm adapters which was of no use and dupe pings were showing up even in Player 6.1 and Workstation 10 (the latest available today)
I've spent a couple days tracking this down on my system. This has been an issue on this system for quite some time, but I've been able to work around it up until now. One system (my main system) was showing the ICMP redirects and the packet traces for ICMP (and TCP) traffic made it look like the host OS (windows 7 in my case) was routing the bridged traffic as reported by itsgnd. The other three vmware installs I tested were fine. The "Routing and Remote Access" service was already disabled.
I ended up following step five in VMware KB: Troubleshooting network connection failures to reinstall the vmware bridge service on the host box. That seems to have done the trick. I had uninstalled vmware 7 and installed vmware workstation 10, but that didn't fix things. Evidently that unintall and reinstall does not reinstall the vmware bridge service (which seems odd).
SO I FOUND THE SOLUTION.
I'm using a MAC and My Internet sharing was on . THats through system preferece and sharing. Once i switched off sharing it fixed the DUP! ping issue.
I'm assuming it would be something similar in Windows 7 like ICS Internet Connection Sharing or Routing and Remote Access