Earlier today, somebody mentioned not being able to get to the internet, but didn’t seem to be having any issues getting to local resources (file server, printers, etc). They also mentioned that they had seen a meesage about IP address conflicts with another computer. This is a little interesting trying to debug, because how do you query a host that is conflicting the IP with another machine? If you’re lucky, one of your queries might go to the conflicting host, othertimes it might not.
Fortunately for us, Microsoft is pretty good when handling IP conflicts, and gives us enough information to get us by. It generates an event log entry with the source “Tcpip”, and event id 4199. In the event, it contains the IP that is at fault, and the MAC1 address of the remote host. The entry looks something like this:
The system detected an address conflict for IP address 10.30.10.164 with the system having network hardware address 00:0B:DB:AA:AA:AA. Network operations on this system may be disrupted as a result.
From this entry, we can see that the local computer was assigned the 10.30.10.164 address, but it conflicted with the host having the MAC 00:0B:DB:AA:AA:AA. Knowing that MAC addresses, or at least the first portion of it, are registered, I dropped by the IEEE site, and looked up what type of machine this came from. This ended up being a Dell computer. This didn’t help a whole huge amount, as 90% of our network is Dell.
So we’re back to square one… almost. We still know the MAC address, and the IP of the other host. This is handy. The MAC address is the most handy portion. On a Cisco switch, you can find the MAC addresses of connected devices really easily, unfortunately we’ve not gone entirely Cisco yet. So I had to rely on Windows itself.
When you ping a computer, if you’ve not communicated with it in the past, and its in your subnet, a broadcast message is sent out to find the MAC address of that IP. In a normal situation, the MAC address is returned correctly. In this case, the MAC might be either of the hosts, it depends on who responds the quickest. You can test the MAC address lookup by looking at your ARP cache. This can be done by using the following command:
arp -a
You should get something like this back:
Z:\>arp -a Interface: 10.30.10.31 --- 0x2 Internet Address Physical Address Type 10.30.10.1 00-17-95-AA-AA-AA dynamic 10.30.10.2 00-14-1c-AA-AA-AA dynamic 10.30.10.10 00-14-22-AA-AA-AA dynamic 10.30.10.11 00-08-c7-AA-AA-AA dynamic 10.30.10.12 00-13-72-AA-AA-AA dynamic 10.30.10.14 00-0c-29-AA-AA-AA dynamic 10.30.10.15 00-0b-db-AA-AA-AA dynamic 10.30.10.24 00-15-c5-AA-AA-AA dynamic 10.30.10.87 00-e0-07-AA-AA-AA dynamic 10.30.10.164 00-18-8b-AA-AA-AA dynamic
As you can see from the above, the MAC address listed for the .164 address doesn’t match that address in the log entry, so that’s the MAC address for the host reporting the conflict. The good news is the arp command isn’t just for viewing the ARP cache2, but you can use it to set static values in it. This is what we’re going to use to locate the problem host. To set a static arp entry, we use the following:
arp -s 10.30.10.164 00-0B-DB-AA-AA-AA
Performing an arp -a command now, will show the new MAC address for this host. Next step is some tools from Sysinternals called pstools. The ones I’m interested in is psloggedon. Combined with the IP address we know, we should be able to resolve who is logged onto the remote computer.
psloggedon \\10.30.10.164
This should return the user of the account that is logged into the remote host. Unfortunately in this case, it didn’t return anything except an error about not being able to find HKEY_USERS. So we resort to some more windows tools, this time ones shipped with windows. nbtstat will allow you to query the remote host, and assuming it responds to the queries, it should give you enough information to establish the hostname, and possible shares.
nbtstat -a 10.30.10.164
This gave us enough information to establish who the machine belogged to. It ended up being a personal desktop from one of the helpdesk guys… And the reason psloggedon didn’t work? It was running RedHat.