In Windows 7, suddenly our development server's name is resolving to the wrong IP address on my machine only. Everyone else is fine. I don't know why, but I suspect it might have been affected by a temporary VPN connection to that server, which I've now deleted. It worked fine earlier today. Stopped mid-afternoon. Now it resolves to the wrong IP address, which as far as I can tell doesn't even exist on the network.
I can access the server by IP, but by name I get the wrong IP resolved and that address doesn't exist. Does anybody know how to troubleshoot this? I don't even know what technology is used to resolve Windows computer names... I can probably solve this with /etc/hosts, but that seems like a h4xy solution (and a static one, at that).
Have you tried turning off all the computers on the network and then turning them all on again at the same time?
Is the host found using DNS or WINS?
As a short term -- you can use the server's ip directly for most things.
Have you tried turning off all the computers on the network and then turning them all on again at the same time?
That would mean stopping everyone's work and stopping services for all clients... That isn't an option; certainly not for me.
Is the host found using DNS or WINS?
I think it's WINS, but I'm not overly familiar with what that means. To my knowledge, it isn't DNS. I didn't have our local DNS server added, but now I do and even after flushing DNS I still get the wrong IP. As far as I know, the name I'm using is the computer name.
As a short term -- you can use the server's ip directly for most things.
In theory, I think I should be able to add an entry to the hosts file also, but if the IP ever changed I'd probably be confused for a bit and I'd really rather solve the problem instead of patch it.
Interestingly enough, today when I came into j0rb, I tried connecting to network shares on this computer and they worked. ping, however, still does not. The IP address that ping gives does not appear to exist (both ping and Windows Explorer time out trying to reach it). SQL Server Management Studio can also connect now though (this was the originally noticed problem; I was unable to reach the development database server by name yesterday afternoon).
Windows uses a WINS protocol that goes over UDP and UDP broadcast. Information about the network is supposed to get sort of 'shared' among everybody and any one computer can screw with what is shared. This is the default mode for WINS.
In the 'advanced' mode there is a dedicated server that controls all the WINS stuff.
Now it's back to working correctly again... :-/ I don't know if things just finally expired and were updated or if something changed on the network. :-X
Spoke too soon. It's broken again. I'm beginning to think there must be a computer on the network screwing with mine... I'm installing Microsoft Network Monitor... Hopefully that will provide me with some clues...
Could be two servers with the same name.
Have you screwed with your computer's network settings lately? -- could be you pressed the wrong checkbox on some dialog box.
I googled around and found a few things.
nbtstat -RR
That should clear the WINS Cache on the client.
How To Diagnose and Test TCP/IP or NetBIOS Network Connections in Windows Server 2003
I did, but nothing complicated. I came back from holidays the beginning of this week and noticed that my IP address was wrong. I remember I was doing some experimentation with NTP a few weeks ago, but I don't think I ever messed with my network settings. There was apparently no explanation from anyone else in the office so I reset it to what it's supposed to be (what is assigned to my workstation by the "network administrator"). At the same time, I was told that I should be using a different gateway (I never know which one we should be using at any giving moment) so I also reset the gateway and DNS info. I've been through all of that since to make sure I didn't screw something up and saw nothing that looked wrong. I looked at the WINS tab for said connection in the advanced dialog and saw nothing that seemed out of place. Of course, I'm assuming everything is still at its default settings because I've never configured anything WINS related before.
If you haven't screwed with the settings -- you could try screwing with the settings. This sometimes works for me.
A packet logger would be interesting. Scan all the UDP broadcast packets windows is sending out. It will be a lot of stuff and not easy to shift through but a great learning experience.
According to this page WINS runs on port 42.
42 UDP Host Name Server - Microsoft WINS
If I filter by port 42 (TCP or UDP) I get no results.
** EDIT **
OK, looking at the log I stumbled across what sounds like an LLMNR request from my computer and a response from the destination computer itself. The odd thing is, inside of the "AnswerRecord" node there are 4 "ResouceRecordData" nodes, each having an "NBAddress" field. The first "ResouceRecordData"'s "NBAddress" is the correct address AFAIK. The forth one though is the wrong address that I've been getting... The other two I've never seen before. What this means, I do not know.
You have to intercept UDP broadcast packets. Is your packet logger setup to do so?