I'm having a strange (and persistent!) problem with pinging local machines on my network by name. I believe my machine (Windows 7 64-bit) is the only one having this issue. This is over a wireless connection.
As an example, consider a device on my network by the name of WDTVLiveHub. It's a Western Digital Live Hub (surprise!). If I go to my router's DHCP Client Table in the browser (my router is a WRT400N), I see this entry:
WDTVLiveHub 192.168.1.101
Great. So I try to ping that IP address:
ping 192.168.1.101
Pinging 192.168.1.101 with 32 bytes of data:
Reply from 192.168.1.101: bytes=32 time=9ms TTL=64
Reply from 192.168.1.101: bytes=32 time=16ms TTL=64
Reply from 192.168.1.101: bytes=32 time=16ms TTL=64
Reply from 192.168.1.101: bytes=32 time=16ms TTL=64
Ping statistics for 192.168.1.101:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 9ms, Maximum = 16ms, Average = 14ms
OK, still looking good. Now I try to ping it by name:
ping WDTVLiveHub
Ping request could not find host WDTVLiveHub. Please check the name and try again.
From what I've read, this implies a problem with DNS servers and host name lookups. Interestingly, if I type the following:
pathping 192.168.1.101
I get this output:
Tracing route to WDTVLIVEHUB [192.168.1.101]
over a maximum of 30 hops:
0 Scotty [192.168.1.103]
1 WDTVLIVEHUB [192.168.1.101]
Computing statistics for 25 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 Scotty [192.168.1.103]
1/ 100 = 1% |
1 12ms 1/ 100 = 1% 0/ 100 = 0% WDTVLIVEHUB [192.168.1.101]
Trace complete.
Scotty is obviously the name of my local machine. So it's able to find the name somehow when I do that approach…
ipconfig /all shows the following under DNS servers:
DNS Servers . . . . . . . . . . . : 192.168.1.1
***.***.***.***
***.***.***.***
Where the * represents the same DNS servers that show up in my router under DNS 1 and DNS 2 through the Internet.
For completeness, here's the whole output of ipconfig /all:
Windows IP Configuration
Host Name . . . . . . . . . . . . : Scotty
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Peer-Peer
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Wireless LAN adapter Wireless Network Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Dell Wireless 1397 WLAN Mini-Card
Physical Address. . . . . . . . . : 0C-EE-E6-D1-07-E8
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2002:d83a:31e5:1234:5592:398e:8968:43d1(Preferred)
Temporary IPv6 Address. . . . . . : 2002:d83a:31e5:1234:ecce:2f79:72a5:5273(Preferred)
Link-local IPv6 Address . . . . . : fe80::5592:398e:8968:43d1%26(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.103(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : September-17-12 11:05:57 PM
Lease Expires . . . . . . . . . . : September-18-12 11:05:57 PM
Default Gateway . . . . . . . . . : fe80::200:ff:fe00:0%26
192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DHCPv6 IAID . . . . . . . . . . . : 537718502
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-80-3D-D7-00-26-B9-0D-08-70
DNS Servers . . . . . . . . . . . : 192.168.1.1
***.***.***.***
***.***.***.***
NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter VirtualBox Host-Only Network:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : VirtualBox Host-Only Ethernet Adapter
Physical Address. . . . . . . . . : 08-00-27-00-98-9A
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::b48a:916b:c0f:fb29%23(Preferred)
Autoconfiguration IPv4 Address. . : 169.254.251.41(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 570949671
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-80-3D-D7-00-26-B9-0D-08-70
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip. . . . . . . . : Enabled
Tunnel adapter Local Area Connection* 15:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Tunnel adapter isatap.{55899375-C31D-4173-A529-4427D63FD28B}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Tunnel adapter isatap.{64B8F35F-A6AB-4D6B-B1D5-DD95F57B1458}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Not sure exactly how to diagnose exactly what's going on… but the problem is really frustrating! The biggest problem is that my mapped network drives have to be done by IP, and then any time the router assigns new IP addresses to those devices, all of my network shares break again. Stinks!
Would love some assistance on possible solutions. I've tried all of this netsh catalog resetting and that didn't seem to fix anything at all. Would love an explanation of what's going wrong, too, rather than blindly resetting things!
UPDATE: I ran Wireshark 1.8.2 to see what was going on when I ran my ping request. Wireshark immediately shows four LLMNR requests to what I believe is the correct multicast destination. Two of them are IPv4 and the other two are IPv6. What I don't see are any ICMP packets? Should LLMNR be expected to work on its own?
UPDATE 2: I'm able to ping another machine (Windows Vista) on the network by name. This jives with the idea that LLMNR is only supported on newer Windows machines, but not on the other devices on my network. I installed WireShark on my other machine, and found that when I ping from there, it also sends out NBNS packets — NetBIOS Name Service. This implies that somehow my machine is not sending out NBNS queries for some reason. Still digging…
UPDATE 3: Just can't seem to send NetBIOS packets. I think this is the root cause. I've tried disabling LLMNR through the group policy hoping that NetBIOS would magically start up, but no luck. ipconfig shows that NetBIOS over TCP/IP is Enabled, and yet WireShark doesn't show any NetBIOS name resolution packets being sent out. I've tried disabling and then re-enabling it. I've also tried the two classic commands of nbtstat winsock reset catalog and nbtstat int ip reset reset.log, but those didn't fix the NetBIOS issues at all. Would LOVE some guidance…
SOLVED! Many, many thanks to wmz. He or she indeed pinpointed exactly the issue: for whatever reason my NetBIOS over TCP/IP had set itself up to act in peer-to-peer mode. After a little research, it turns out peer-to-peer mode only works if you have a WINS server set up (which I definitely don't!). I dug into the registry and found no entries under NodeType, but indeed an entry for DhcpNodeType with the (horror of horrors!) value of 0x00000002. A value of 1 is Broadcast (which would have been fine), 2 is Peer-to-Peer (requiring a WINS server! Ack!), 4 tries WINS server then broadcasts, and 8 tries broadcast then WINS server (called "Hybrid" mode). After deleting the DhcpNodeType entry and rebooting, I found that ipconfig /all now showed Hybrid mode. So it looks like that's the default for Windows 7 Ultimate 64-bit. I tried pinging wdtvlivehub, and was immediately greeted with the sweet taste of success. Many thanks to all of you for your various answers. I'm very happy to have solved the problem without reinstalling Windows or some crazy thing. I still have no idea how this value ever got changed… but at least it's one more thing to look for and hopefully this info helps somebody else dealing with frustrating networking issues! Feels so good to have this problem licked! Bounty well earned!
Thanks!
Best Answer
Your findings seem to point to netbios resolver, which in turn makes this entry a suspect:
Node Type . . . . . . . . . . . . : Peer-PeerNetbios node type p(2) - normally used only with Wins server (which I assume you do not have) - effectively disables any netbios name resolution broadcast.
This article describles problem very similar to yours and also links to Msoft technet article detailing how to reset node type to something more reasonable: