VMware Communities
iainwb
Contributor
Contributor

Yet another "IP address conflict" issue

I know there have been several threads, but I've dug through everyone one I've found with no success. This seems to be different.

A Win7 VM I've had for a long time has started reporting IP address conflicts, but they're guaranteed false.I don't know when the failure mode started, as I haven't used this VM for a while, but it could have been upon moving to a Dell from the Thinkpad I used for a couple of years.

The VM has three NICs configured. One uses Bridged/wired (VMnet0), one uses Bridged/wifi (VMnet2) and one uses host only. The one bridged to wifi always gives "Windows has detected an IP address conflict." It does this on every wifi network, even ones that are otherwise empty - which is how I know it's bogus. The MAC addresses don't conflict with anything on the notebook, and there's nothing else they could conflict with. It doesn't matter which of the three virtual NICs is mapped to the wifi adapter, it's always the wifi connection that fails.

I have never seen a problem with any of my XP VMs.

The system log message is "The system detected an address conflict for IP address 0.0.0.0 with the system having network hardware address 24-77-03-85-1B-A4. Network operations on this system may be disrupted as a result." 24-77-03-85-1B-A4 is the MAC address of the host wifi adapter, but I sincerely doubt the router would have handed out a 0.0.0.0 address by DHCP Smiley Happy. And again, even if the router was doing weird stuff, this is three separate wifi networks, with different hardware and DHCP providers.

I can only imagine that either a) I have something screwed up in my VMX file or b) VMware doesn't play well with my NIC. I upgraded from 7.x to 9.0.0 today mostly in an attempt to solve this, but no change.

Wifi NIC is listed in network editor as Intel(R) Centrino(R) Ultimate-N 6300 AGN

Wired NIC is Intel(R) 82579LM Gigabit Network Connection

Or maybe I won't attach the VMX because it's encrypted, but I can decrypt the VM if that would help resolve this.

Any suggestions?

Reply
0 Kudos
35 Replies
onoski
Enthusiast
Enthusiast

Jugding from my experience with a similar issue in a virtual environment the resolution was by accessing the registry and deleting network card addresses that were of no use. This has to be done by typing regedit via the start button and run, then right click on hkey machine and do a find for network cards.

Best wishes.

WoodyZ
Immortal
Immortal

I agree with the concept that onoski presented however I would stay out of the Windows Registry unless you had no other choice and instead use the information in Removing hidden or ghosted devices from a Windows virtual machine to remove any installed Network Adapters that are no longer present.

iainwb
Contributor
Contributor

I certainly see ghosted devices. It seems that the problem is the move from the old PC to this one, because the device name is the NIC on that machine. Uninstalling (from that link) seems not to be working, though. I get a short progress bar, but the device remains. I may end up having to find them in the registry after all. Or might I be able to uninstall them from safe mode?

Reply
0 Kudos
iainwb
Contributor
Contributor

I'm still drawing a blank. What appeared to be ghosted devices may just have been Symantec Endpoint. I have uninstalled Symantec, OpenVPN, Nortel VPN (both of which added TAP/TUN devices) and removed all three network cards from device manager, since uninstalling the "ghost" devices failed silently. Windows reinstalled the three NICs correctly, and as far as I can tell, all network devices are legitimate, now. I still see the address conflict message, and can't connect to bridged wifi. Here's a screenshot of my network adapters, including viewing hidden devices. Does it look reasonable?

devices.png

Reply
0 Kudos
iainwb
Contributor
Contributor

Still drawing a complete blank with this, if anyone has any ideas. The apparent ghost devices were only Symantec's drivers. Uninstalling the NICs and allowing Windows to reinstall them didn't help. The miniport drivers appear to be legitimate, and I trashed the system completely by trying to delete them.

So, different approach: I went back to my original VM on the original notebook. I uninstalled the VPN and Symantec. I verified that networking was fine on wired, wireless and host-only. Then I uninstalled the three NICs from device manager so that the new machine would install them cleanly. Copied the VM over to the new machine and started it up. Success! All three NICs installed and I could ping everywhere.

Ten minutes later, "Windows has detected an IP address conflict." Again, it was on the wireless card, on the wifi network that no one else was using.

Reply
0 Kudos
louyo
Virtuoso
Virtuoso

Well, this may be a stupid suggestion, but I have seen similar to this when routers were piggybacked and a connection was moved from one subnet to another. The main router did not like seeing the same MAC address on different subnets even though it was not at the same time. In our case, power cycing the Internet connected Firewall (a Sonicwall) cleared out the cache and resolved the problem. The address conflict had to do with the MAC address, more so than the IP address. I would make sure there were no MAC conflicts with any NIC's, wireless or otherwise.

Lou

Reply
0 Kudos
iainwb
Contributor
Contributor

Not a stupid suggestion at all, IMO. That occured to me, and is part of the reason I've been trying so many different networks. I think I've eliminated that as a possibility, since each network I tried has a different DHCP/routing mechanism, and is completely isolated from the others.

1: Linksys router on old DMZ. We keep this IP block for testing and for a comletely isolated mail server. The provider is different from the one we use for the regular company network access. I connect to a router which is set up as an access point, with another Linksys router providing DHCP, so this is certainly a place where connecting to the other router could cause a MAC address conflict if the tables weren't updated. No-one else uses this router.

2. Linksys router on new DMZ. Router provides DHCP. Isolated by a NAT firewall from internal private network. Set up for customer access; rarely but occasionally used.

3. Linksys WAP on internal private network. Not entirely sure which machine provides DHCP, but it isn't the WiFi link. I think it's a Linux box somewhere. Usually has a few users.

4. Linksys router at home, with DHCP provided by an external Linux server. My iPhone, my notebook, my wife's notebook on wifi, maybe another four or five devices on wired side, but I have logs and don't see a MAC collision.

I think between all of those there's enough options that if there really were a MAC conflict on one, it wouldn't be repeated on the others. Plus, looking at the logs from home I can clearly see that there are no MAC collisions in the log, and that DHCP is working fine; it's the virtual machine which is rejecting the addresses.

(See below.)

Reply
0 Kudos
iainwb
Contributor
Contributor

One more point of information that seems fairly worthless, but at least verifies that the IP stack and virtual interface appears to be working just fine.

Looking at logs of the DHCP server at home, I see the virtual machine (priss) requesting an address, being assigned an address, and immediately declining that address. I suppose I could have looked at arp requests with tcpdump; I completely forgot to do so, but it seems incredibly unlikely that Windows could have detected an address conflict, particularly since there isn't one. Also since the server continues to assign new addresses which are declined there couldn't be ongoing address conflicts, since there aren't that many machines physically on the network.

It seems to me that it has to be an issue with the virtualized adapter not working with Windows 7. Maybe "IP address conflict" is a default message, or maybe Windows declines all DHCP offers, and then it gives "IP address conflict" when the server rolls back around and assigns an address that Windows has seen before. That would account for the fairly long delay before seeing the error popup. I'm puzzled why a) it works fine under XP, and b) it's only this one adapter type, since the one in the old notebook appears to work perfectly.

Logs from my DHCP server (including a couple of successful offers to other machines. midori is the host, priss is the VM. Both are Windows 7/64).

Sep 25 17:49:00 chloe dhcpd: DHCPREQUEST for 192.168.32.91 from 00:1b:2f:a4:d3:4f (WGPS606) via eth1
Sep 25 17:49:00 chloe dhcpd: DHCPACK on 192.168.32.91 to 00:1b:2f:a4:d3:4f (WGPS606) via eth1
Sep 25 17:49:02 chloe dhcpd: DHCPREQUEST for 192.168.32.80 from 22:aa:4b:85:1b:a4 (midori) via eth1
Sep 25 17:49:02 chloe dhcpd: DHCPACK on 192.168.32.80 to 22:aa:4b:85:1b:a4 (midori) via eth1
Sep 25 17:49:24 chloe dhcpd: DHCPDISCOVER from 00:0c:29:8e:2c:04 via eth1
Sep 25 17:49:25 chloe dhcpd: DHCPOFFER on 192.168.32.86 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:28 chloe dhcpd: DHCPDISCOVER from 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:28 chloe dhcpd: DHCPOFFER on 192.168.32.86 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:29 chloe dhcpd: Added new forward map from priss.home.webl.com to 192.168.32.86
Sep 25 17:49:29 chloe dhcpd: added reverse map from 86.32.168.192.in-addr.arpa. to priss.home.webl.com
Sep 25 17:49:29 chloe dhcpd: DHCPREQUEST for 192.168.32.86 (192.168.32.5) from 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:29 chloe dhcpd: DHCPACK on 192.168.32.86 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:29 chloe dhcpd: Abandoning IP address 192.168.32.86: declined.
Sep 25 17:49:29 chloe dhcpd: DHCPDECLINE of 192.168.32.86 from 00:0c:29:8e:2c:04 (priss) via eth1: not found
Sep 25 17:49:39 chloe dhcpd: DHCPDISCOVER from 00:0c:29:8e:2c:04 via eth1
Sep 25 17:49:40 chloe dhcpd: DHCPOFFER on 192.168.32.72 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:40 chloe dhcpd: Added new forward map from priss.home.webl.com to 192.168.32.72
Sep 25 17:49:40 chloe dhcpd: added reverse map from 72.32.168.192.in-addr.arpa. to priss.home.webl.com
Sep 25 17:49:40 chloe dhcpd: DHCPREQUEST for 192.168.32.72 (192.168.32.5) from 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:40 chloe dhcpd: DHCPACK on 192.168.32.72 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:40 chloe dhcpd: Abandoning IP address 192.168.32.72: declined.
Sep 25 17:49:40 chloe dhcpd: DHCPDECLINE of 192.168.32.72 from 00:0c:29:8e:2c:04 (priss) via eth1: not found
Sep 25 17:49:50 chloe dhcpd: DHCPDISCOVER from 00:0c:29:8e:2c:04 via eth1
Sep 25 17:49:51 chloe dhcpd: DHCPOFFER on 192.168.32.89 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:54 chloe dhcpd: DHCPDISCOVER from 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:54 chloe dhcpd: DHCPOFFER on 192.168.32.89 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:54 chloe dhcpd: Added new forward map from priss.home.webl.com to 192.168.32.89
Sep 25 17:49:54 chloe dhcpd: added reverse map from 89.32.168.192.in-addr.arpa. to priss.home.webl.com
Sep 25 17:49:54 chloe dhcpd: DHCPREQUEST for 192.168.32.89 (192.168.32.5) from 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:54 chloe dhcpd: DHCPACK on 192.168.32.89 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:58 chloe dhcpd: DHCPREQUEST for 192.168.32.89 (192.168.32.5) from 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:58 chloe dhcpd: DHCPACK on 192.168.32.89 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:49:59 chloe dhcpd: Abandoning IP address 192.168.32.89: declined.
Sep 25 17:49:59 chloe dhcpd: DHCPDECLINE of 192.168.32.89 from 00:0c:29:8e:2c:04 (priss) via eth1: not found
Sep 25 17:50:09 chloe dhcpd: DHCPDISCOVER from 00:0c:29:8e:2c:04 via eth1
Sep 25 17:50:10 chloe dhcpd: DHCPOFFER on 192.168.32.75 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:50:10 chloe dhcpd: Added new forward map from priss.home.webl.com to 192.168.32.75
Sep 25 17:50:10 chloe dhcpd: added reverse map from 75.32.168.192.in-addr.arpa. to priss.home.webl.com
Sep 25 17:50:10 chloe dhcpd: DHCPREQUEST for 192.168.32.75 (192.168.32.5) from 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:50:10 chloe dhcpd: DHCPACK on 192.168.32.75 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:50:10 chloe dhcpd: Abandoning IP address 192.168.32.75: declined.
Sep 25 17:50:10 chloe dhcpd: DHCPDECLINE of 192.168.32.75 from 00:0c:29:8e:2c:04 (priss) via eth1: not found
Sep 25 17:50:20 chloe dhcpd: DHCPDISCOVER from 00:0c:29:8e:2c:04 via eth1
Sep 25 17:50:21 chloe dhcpd: DHCPOFFER on 192.168.32.97 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:50:21 chloe dhcpd: Added new forward map from priss.home.webl.com to 192.168.32.97
Sep 25 17:50:21 chloe dhcpd: added reverse map from 97.32.168.192.in-addr.arpa. to priss.home.webl.com
Sep 25 17:50:21 chloe dhcpd: DHCPREQUEST for 192.168.32.97 (192.168.32.5) from 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:50:21 chloe dhcpd: DHCPACK on 192.168.32.97 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:50:21 chloe dhcpd: Abandoning IP address 192.168.32.97: declined.
Sep 25 17:50:21 chloe dhcpd: DHCPDECLINE of 192.168.32.97 from 00:0c:29:8e:2c:04 (priss) via eth1: not found
Sep 25 17:50:31 chloe dhcpd: DHCPDISCOVER from 00:0c:29:8e:2c:04 via eth1
Sep 25 17:50:32 chloe dhcpd: DHCPOFFER on 192.168.32.81 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:50:35 chloe dhcpd: DHCPDISCOVER from 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:50:35 chloe dhcpd: DHCPOFFER on 192.168.32.81 to 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:50:35 chloe dhcpd: Added new forward map from priss.home.webl.com to 192.168.32.81
Sep 25 17:50:35 chloe dhcpd: added reverse map from 81.32.168.192.in-addr.arpa. to priss.home.webl.com
Sep 25 17:50:35 chloe dhcpd: DHCPREQUEST for 192.168.32.81 (192.168.32.5) from 00:0c:29:8e:2c:04 (priss) via eth1
Sep 25 17:50:35 chloe dhcpd: DHCPACK on 192.168.32.81 to 00:0c:29:8e:2c:04 (priss) via eth1

Reply
0 Kudos
iainwb
Contributor
Contributor

Two more failed experiments:

- Tried changing virtual adapter to vmxnet3. No change.

- Tried disabling IPV6 in Windows. No change.

ipconfig /all shows thsi:

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection
   Physical Address. . . . . . . . . : 00-0C-29-8E-2C-04
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Autoconfiguration IPv4 Address. . : 169.254.184.239(Duplicate)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :
   NetBIOS over Tcpip. . . . . . . . : Enabled

Maybe the IP address conflict is just the bogus network address that's flagged as "Duplicate" and is only a symptom of failing to acquire an address on the 192.168.31 network.

Reply
0 Kudos
louyo
Virtuoso
Virtuoso

Anything in the event logs? I have seen some discussions around a device refusing an address if any other NIC in the system had that address already, even if it was not on line.

If your DHCP servers are not set to the same subnets or overlapping ranges, it should rule that out. Do you assign any IP's based on MAC?

As you said the 169.254.xxx.xxx is just the range used by the system when no DHCP is assigned by a server (this can let machines communicate when there is no DHCP server). I don't ever recall it ever saying duplicate though.

Sorry I can't be more help.

Lou

Reply
0 Kudos
iainwb
Contributor
Contributor

Thanks for reminding me. I did check the event logs before, but the result added to the confusion, since it claimed that the IP address in conflict was 0.0.0.0 and was owned by the host's wifi adapter (which the problem virtual device is bridged to). I just checked and I'm still seeing the same, but it still makes no sense to me.

Reply
0 Kudos
iainwb
Contributor
Contributor

For the sake of completeness, here's the host's relevent ipconfig/all for that device

Reply
0 Kudos
louyo
Virtuoso
Virtuoso

Last time I will bother you Smiley Happy

All of my VM's are assigned static IP's. I seem to recall one time, when I moved/copied a VM that the static setting was gone and it was reset to DHCP. When I went to reset the static IP address, I got a dialog telling me that another NIC (there weren't any others) in the system already had that IP address and that maybe I should choose another. My memory is failing me here but I think I said no, use the IP I told you to and it started working. In fact, I think my first try was to look in device manager and there were no others and deleting/reinstalling the NIC didn't fix it. You might try assigning a static address (if you haven't done so already) and if that works, try going back to DHCP.

Sorry, a little fuzzy here.

Lou

Reply
0 Kudos
iainwb
Contributor
Contributor

Easy enough to try. Thanks for the suggestion.

Reply
0 Kudos
iainwb
Contributor
Contributor

No go Smiley Sad. Failed to take the static address (showed up as blank in ipconfig, and ping gave 'general failure'), then switching back gave same results as before.

Reply
0 Kudos
louyo
Virtuoso
Virtuoso

That would seem to rule out the routers, which you had already decided. Might be an easier symptom to work against, especially if you use a completely different subnet, like 10.10.10.0. BTW: what happens if you ping 127.0.0.1 from within the VM?

If you have your VM backed up, I would probably try removing any/all network cards as already suggested, then let the OS reinstall. If that doesn't do it, I would try doing some troubleshooting with NETSH.

Lou

Reply
0 Kudos
MaxVan
Contributor
Contributor

Hi Ian,

I have a exactly the same error as you described.

Do you also have the following warning in your eventvwr?

Log Name:      System
Source:        Microsoft-Windows-DNS-Client
Date:          27/09/2012 16:22:19
Event ID:      1014
Task Category: None
Level:         Warning
Keywords:     
User:          NETWORK SERVICE
Computer:      VMWIN7
Description:
Name resolution for the name isatap.lan timed out after none of the configured DNS servers responded.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-DNS-Client" Guid="{1C95126E-7EEA-49A9-A3FE-A378B03DDB4D}" />
    <EventID>1014</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x4000000000000000</Keywords>
    <TimeCreated SystemTime="2012-09-27T14:22:19.593506300Z" />
    <EventRecordID>5246</EventRecordID>
    <Correlation />
    <Execution ProcessID="1060" ThreadID="2192" />
    <Channel>System</Channel>
    <Computer>VMWIN7</Computer>
    <Security UserID="S-1-5-20" />
  </System>
  <EventData>
    <Data Name="QueryName">isatap.lan</Data>
    <Data Name="AddressLength">16</Data>
    <Data Name="Address">02000035C0A801010000000000000000</Data>
  </EventData>
</Event>

Reply
0 Kudos
CArl_51
Contributor
Contributor

The issue was very well described throughout this post. I have the same issue.

  • Windows 7 virtual machine 64-bit. Ultimate edition.
  • Virtual machine bridge to a wireless connection.
  • The VM declines the offered IP address because of a conflict with 0.0.0.0.
  • The Cisco router receives the message, marks the offered address is conflicting.
  • The Cisco router then offers another address
  • The virtual machine then declines this address is conflicting
  • The Cisco router marks this address as conflicting
  • Eventually all available addresses in the pool are marked as conflicting.
  • The router DHCP pool is now depleted and no addresses can be offered to other network devices.
  • Any network devices which had previously received an IP address, but were powered down past lease expiration, receive an IP address conflict message when they are started up and request to renew their previous IP address.
Reply
0 Kudos
iainwb
Contributor
Contributor

I've already removed the devices and let the OS re-install, and I've tried four completely isolated class C networks. I can ping 127.0.0.1.

netsh might be useful, if I knew how to drive it :/. I've used it to reinitialize the IP stack a couple of times; beyond that I'm not sure what I'd accomplish with it.

Reply
0 Kudos