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 
. 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?
So it seems like the common factor is the NIC, although not completely identical model numbers. Intel Centrino advanced/ultimate 6200/6300 series. (Likely identical drivers, however.)
Is there any way to submit a bug report? I guess I don't have the free month's support with the upgrade that I had when first buying VMWare
- Start - Run - type "MMC" - Enter
- File - Add/Remove Snap-in - Group Policy Object for local computer.
- Computer Configuration/Windows Settings/Security Settings/Network List Manager Policies
- Under Unidentified Networks Properties, select Private and Uses can change location.
- Exited out of that and then from a command prompt did a gpedit /force
On each guest VM I changed the network settings from "Bridged: Connected directly to the physical network" to "Custom: specific virtual network" and they are all now working! Haven't tried changing the NIC to use DHCP as I want these to be all static, so if someone does that let us know. I am also not sure if you can just configure the Group Policy and use the original VMnet0 networking option.
Since the failure I'm experiencing is specifically with DHCP, it seems like this would be a different problem. I did try tweaking group policy with no effect - but then I have no idea what I'm doing . Still, I can't survive with a static IP because of the number of wifi networks I need to use.
I do already have the adapter set to custom and tied to the wifi NIC.
To be able to work I've switched to using NAT for now, which works for 90% of what I need, but sometimes I do also need to have that VM visible from the net, and then NAT won't work.
To the previous comment regarding er650 and multiple IP's, I tend to agree.
With regard to your last response to me, Stick with me for a second. :
- You are using DHCP on the host computer (I assume) and then using DHCP on the VMware guest computer that you are building. Is that correct?
- You are getting the following error message, and you are seeing this error message on your wireless router/switch/AP?
- 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: DHCPREQUEST for 192.168.32.86 (192.168.32.5) from 00:0c:29:8e:2c:04 (priss) via eth1
- The MAC address 00:0C:29:8E:2C:04 is the MAC for the wireless NIC on your host computer which also has the IP address 192.168.32.5 assigned to it. 192.168.32.86 is the IP address being offered that is being declined. And if you wait, the 32.86 is then 32.87 then 32.88, is that correct?
On my side I am using a static IP address for my guest Virtual Machines, and I am seeing a similar denial in the logs. I am using a Juniper firewall but the rest seems to be the same. So:
- VM has a static IP address
- Getting a message in the log that I see in the Firewall that has a request for an IP to the MAC of the Host.
- The log then says that the Virtual Machine with the STATIC IP address has declined the IP address. and then goes to the next IP address.
Whats weird is that it does not seem to matter about Static vs. DHCP on the Virtual Guest side. And for other descriptions outside of this one but with very similar results, this does lookk to be the same issue.
Question for you: When you first set this up, does it all work for awhile and then suddenly stop and you haven't been able to get it working again? If yes, I think this is the same issue. If no, then we probably do have different issues.
Private IM me if you want. I think we are close.
Okay, so I just deleted a huge long reply that I was answering point-by-point. I think you're right on all counts, except that the 192.168.32.5 is actually the DHCP server, not the VM host. The host is at .80.
I had forgotten that at one point I tried to use a static address and also failed.
I don't see why a static address would make a DHCP request but it does make an ARP who-has request to ensure that the address is not in use. Perhaps the reason for the DHCP DECLINE is that there's an ARP who-has after the offer and prior to committing to it.
After typing all of that up (the long version), I realized that might be exactly what's going on, if the stuff below is true:
What I might be missing is this: >> On each guest VM I changed the network settings from "Bridged: Connected directly to the physical network" to "Custom: specific virtual network" and they are all now working! <<
If that's something that you do with the administrative policy that you added, then bingo. I'm not doing that because I don't understand it . I wouldn't have expected that Windows would be aware of bridging. I would have thought it simply saw a virtual NIC that appeared to be connected directly to an ethernet cable. If both Windows and VMWare are setting up bridging, that could cause conflicts. I could certainly believe that Windows is issuing an ARP who-has to its bridged device, and the VMWare bridged device is replying "here I am." Since that would be entirely internal, I would probably not even see that on the wire.
Anyway, if that is what you mean by that sentence I will definitely need to PM you for help with MMC. Google has not been my friend there, nor has the MMC help which appears to assume you already know what you're doing . Unfortunately, I'm without the notebook now for a few days; likely I'll have it back Friday this week or Monday next.
More info. I ran wireshark on the host specifically looking for ARP requests. I see an ARP request for the gateway, which is answered (two request/reply pairs for some reason) and an ARP request for the assigned address with no reply, as expected, but followed by the DHCPDECLINE. Then I ran the same on the guest VM with similar but subtly different results, and I'm not sure if the differences are as expected or are a problem.
Comments and observations:
* I have disabled everything I can in the adapter properties on Win7, including IPv6 and Microsoft networking. The only checkbox enabled is IPv4.
* I have no idea what the IGMP traffic is setting up or if it could be a problem. It seems unlikely.
* I haven't expanded the DHCP Offer/Ack, but I've walked through several other transactions, and it appears correct. In this case it was assigned 192.168.34.131.
* There are two requests by the VMware ethernet address (Vmware_8e:2c:04) for the address of the router, 192.168.34.1. Both get a reply from the Linksys router (Cisco-Li_f6:46:8e)
* There is an ARP request by the VMware ethernet address for 192.168.34.131. This should have no reply, because that would mean the address already exists on the LAN.
* There is a subsequent ARP request by the Wifi adapter's address (IntelCor_85:1b:a4) for 192.168.34.131.
* There is no reply to either of those ARP requests (as expected)
* Immediately after these requests is the DHCPDECLINE.
Differences on the host side: I'm not going to post a screenshot because they would be for different transactions and misleading, but:
* All ARP requests originate from the Intel address
* The Linksys router replies to the Intel address (which becomes the VMware device in the guest)
* There is only one request for 192.138.34.131 on the host side, originating from the Intel address, still with no reply, of course.
So a couple of options present themselves:
* The ARP who-has issued by the guest is getting an invisible reply; something in the driver layer recognizes the address as assigned to the wifi adapter and is answering without the traffic being visible to Wireshark. This seems unlikely, but it could be a bug in virtualization code.
* The call to send the who-has is not behaving precisely in the virtual driver as it would be for the host talking directly to the card, and Windows is finding an error. (On reflection, both of these are bogus. The adapter, virtualized or not, is on the other side of Wireshark's monitoring from the Windows IP stack. What's causing the failure has to be visible to Wireshark.)
* The ARP who-has issued by the Intel device for its own address is being seen as a separate device claiming ownership of that address. What makes me suspect this is that the ARP requests for the router's address are not visible to the guest. It doesn't see the requests, only the translated replies. However the ARP request from IntelCor_85:1b:a4 for 192.168.34.131 is visible to Wireshark. Perhaps the Windows ethernet layer sees that request, considers that there is another device requesting the same IP address and bombs out.
I've googled several references to a related problem in Win7/Vista. This final ARP who-has is apparently new behaviour. In one case the router was replying to that who-has, and it wasn't possible to get an IP address. I haven't found precisely what I'm seeing here, though, which is a decline after no ARP reply or a different device's ARP request.
I've also found references to "disabling Windows address conflict detection," but nowhere that would tell me how, if it's even possible. All I could find was a router setting, not client-side.
I ran the same test on my old notebook with the same guest VM (Intel 5100 AGN wifi card). There is no echoed ARP request, and no decline. I really don't think that I should be seeing the request from the adapter's ethernet address in the guest; I think that's what's killing the DHCP setup.
Interestingly, though, there's only a single ARP request for 192.168.34.1. I have no idea whether that's significant.
