Bridged Network : Duplicate Ping and no network

[Third_of_Five]

I have a FC7 VM (clean setup of FC7) running in vmware player using a bridged network. DHCP has assigned an IP address: 192.168.5.206

However connectivity to the rest of the network isnt working and if I try and ping anything beyond the VM itself I get ping reporting (DUP!) responses.

ping localhost is ok

ping 192.168.5.206 is ok

ping 192.168.5.169 (another device on the network, doesnt matter which device I choose) reports DUP! responses.

If I switch to NAT and reboot the VM, ping and network access is fine.

Any ideas?

Config file :

config.version = "8"

virtualHW.version = "4"

memsize = "1024"

memtrimrate = "-1"

extendedConfigFile = "RHL.vmxf"

virtualHW.productCompatibility = "hosted"

displayName = "Empty RHL VM"

guestOS = "redhat"

scsi0.present = "TRUE"

scsi0:0.present = "TRUE"

scsi0:0.fileName = "root.vmdk"

scsi0:0.redo = ""

scsi0:1.present = "TRUE"

scsi0:1.fileName = "u1.vmdk"

scsi0:1.redo = ""

ide1:0.present = "TRUE"

ide1:0.fileName = ""

ide1:0.deviceType = "cdrom-image"

ide1:0.autodetect = "TRUE"

floppy0.fileName = "A:"

floppy0.present = false

priority.grabbed = "normal"

priority.ungrabbed = "normal"

ethernet0.present = "TRUE"

ethernet0.addressType = "generated"

ethernet0.generatedAddress = "00:0c:29:3c:8b:0e"

ethernet0.generatedAddressOffset = "0"

tools.upgrade.policy = "manual"

tools.remindInstall = "TRUE"

uuid.action = "create"

checkpoint.vmState = "RHL.vmss"

uuid.location = "56 4d d6 8a 96 79 e7 c2-97 1c cc f4 2e 3c 8b 0e"

uuid.bios = "56 4d d6 8a 96 79 e7 c2-97 1c cc f4 2e 3c 8b 0e"

ethernet0.connectionType = "bridged"

[PJN]

Hi, do you have vmtools installed (looks like you don't from the config file). I think that you need vmtools from bridged to work.

[Third_of_Five]

You dont need vmware tools for bridged to work, or at least you dont using vmware server, as I have several linux VMs running bridged just fine on vmware server. I doubt player is any different.

[Third_of_Five]

Tried uninstalling and re-installing the player (its the latest version 2.0.2-59824) and it still has the same problem.

[PJN]

Fair enough - I suppose that getting a DHCP address assigned shows that it's working to some extent (doh!).

[Third_of_Five]

Yeah. I have since installed vmware-tools on the guest, lsmod shows vmxnet is loaded. and I still get the same problem.

I think its a problem with the player. I am copying another pre-installed linux VM that I use on vmware server ok to my laptop to try that on the player to verify if its a general player problem or specific to the FC7 VM.

The FC7 VM was setup using the boot from iso image hack, using an empty VM created with vmware server. I dont think that should cause a problem though.

I dont have another machine with the player installed (or that I can install it on) which would have been useful.

Im hoping someone knows which knob to twiddle to make this work.

[Third_of_Five]

Interestingly, a w2k VM I have, which was created using vmware converter, is working fine in bridged mode.

[skrodahl]

First of all, check the arp table of your virtual machine for duplicates

'arp -a'

Then run the command 'arp -d *' to clear the arp table, and check if the problem persists.

Second, try setting the IP address manually (as opposed to getting DHCP address), and see if the same happens.

(All while using bridged networking)

[Third_of_Five]

arp -a

Interface: 192.168.5.204 --- 0x10007 (WLAN)
Internet Address Physical Address Type
192.168.5.169 00-50-7f-d6-d4-b8 dynamic
192.168.5.174 00-50-8d-f7-f3-c1 dynamic
192.168.5.175 00-13-02-e3-62-0c dynamic
Interface: 10.111.140.21 --- 0x10008 (Cisco VPN connection)
Internet Address Physical Address Type
10.118.43.1 00-50-7f-d6-d4-b8 dynamic
10.118.43.50 00-50-7f-d6-d4-b8 dynamic

It doesnt seem to matter if I have the Cisco VPN connection open or not.

• After an arp -d, the same problem exists.

• setting static details I still get same problem.

There is some network connectivity. Obviously DHCP was working. Ping is working of sorts appart from the DUP responses.

I have found I can telnet and ssh to other hosts on the same LAN just fine, but not to hosts beyond the LAN even using IP address (I am aware that DNS isnt working atm).

The default gateway is configured correctly and showing in netstat -nr, and I can ping hosts outside the LAN but I get a DUP response when I do.

If I use Microsoft Network Monitor on the host, on the WLAN I can see 1 ping going out and 2 coming back.

5 0.760742 192.168.5.175 213.146.128.34 ICMP ICMP: Echo Request Message, From 192.168.5.175 To ???.???.128.34

6 0.864257 213.146.128.34 192.168.5.175 ICMP ICMP: Echo Reply Message, To 192.168.5.175 From ???.???.128.34

7 0.864257 213.146.128.34 192.168.5.175 ICMP ICMP: Echo Reply Message, To 192.168.5.175 From ???.???.128.34

yet on the target server, i see only 1 response sent

15:26:56.664124 ???.???.106.169 > ???.???.128.34: icmp: echo request (DF)

15:26:56.664147 ???.???.128.34 > ???.???.106.169: icmp: echo reply

By the looks of it (tracing a working telnet from the VM to a machine on the LAN) all inbound packets are being duplicated not just ICMP ones, which doesnt happen if I telnet from the host to a box on the LAN (across the same WLAN interface).

[pfrancois]

I get the duplicate response as well.

I have 2 VMs one solaris10 using vmxnet0 and one sles9 with eth0. The host running VMware server 2.0 beta is a Windows 2003.

Using the "virtual network editor" tool, I've disabled everything (dhcp, nat, vmnet1, vmnet8) except bridging, applied to the only (wireless) network interface I'm using for the test.

I've configured a static IP address for each VM, available on the LAN that the W2K3 connects to.

I get the same symptom from each VM, when pinging to a third party device on that LAN :

A first echo reply: source macaddress= 3rd party-device, source IP=3rd-party device ; destination macaddress = W2K3, destination IP = VM

and... a second echo reply: source macaddress= W2K3, source IP=3rd-party device; desintation macaddress=W2K3, desrtination IP=VM.

as seen from W2K3 standpoint, with a sniffer active on that network interface.

[kuzeyka]

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)