Ping "replies" from same computer with 'Destination host unreachable' (no route to other computer)
I've got two computers in a LAN behind a wireless router.
One has XP with ip 192.168.1.2
This one has W7 with ip 192.168.1.7
If I try to ping the other one from this computer, I get this:
C:\Users\Srekel>ping 192.168.1.2
Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.7: Destination host unreachable.
Reply from 192.168.1.7: Destination host unreachable.
Reply from 192.168.1.7: Destination host unreachable.
Reply from 192.168.1.7: Destination host unreachable.
Ping statistics for 192.168.1.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Tracert gives the same result:
C:\Users\Srekel>tracert 192.168.1.2
Tracing route to 192.168.1.2 over a maximum of 30 hops
1 Kakburken4 [192.168.1.7] reports: Destination host unreachable.
Trace complete.
Although I can ping and tracert the router without any problems. I have disabled the firewalls on both computers. The router is set to use DHCP (if that matters).
Here is the output from "route".
C:\Users\Srekel>route print
===========================================================================
Interface List
13...00 25 86 df c6 89 ......TP-LINK Wireless N Adapter
12...e0 cb 4e 26 b9 84 ......Realtek PCIe GBE Family Controller #2
11...e0 cb 4e 26 be 94 ......Realtek PCIe GBE Family Controller
1...........................Software Loopback Interface 1
16...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
14...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.7 20
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.1.0 255.255.255.0 On-link 192.168.1.7 276
192.168.1.7 255.255.255.255 On-link 192.168.1.7 276
192.168.1.255 255.255.255.255 On-link 192.168.1.7 276
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.1.7 276
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.1.7 276
===========================================================================
Persistent Routes:
None
IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
14 58 ::/0 On-link
1 306 ::1/128 On-link
14 58 2001::/32 On-link
14 306 2001:0:5ef5:73ba:881:20c1:3f57:fef8/128
On-link
14 306 fe80::/64 On-link
14 306 fe80::881:20c1:3f57:fef8/128
On-link
1 306 ff00::/8 On-link
14 306 ff00::/8 On-link
===========================================================================
Persistent Routes:
None
I've set up and debugged a few networks in my life but I'm not really an advanced network user, so I'm not sure what might be wrong. Any ideas? Oh, and pinging this computer from the other computer doesn't work either.
EDIT: Adding arp output:
C:\Users\Srekel>arp -a
Interface: 192.168.1.7 --- 0xd
Internet Address Physical Address Type
192.168.1.1 00-1f-33-ef-28-01 dynamic
192.168.1.255 ff-ff-ff-ff-ff-ff static
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.252 01-00-5e-00-00-fc static
239.255.255.250 01-00-5e-7f-ff-fa static
255.255.255.255 ff-ff-ff-ff-ff-ff static
Adding ipconfig...
C:\Users\Srekel>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : Kakburken4
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Wireless LAN adapter Wireless Network Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TP-LINK Wireless N Adapter
Physical Address. . . . . . . . . : 00-25-86-DF-C6-89
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.1.7(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 09 April 2010 23:09:45
Lease Expires . . . . . . . . . . : 10 April 2010 23:09:45
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.1
NetBIOS over Tcpip. . . . . . . . : Enabled
Ethernet adapter Local Area Connection 2:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller #2
Physical Address. . . . . . . . . : E0-CB-4E-26-B9-84
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Ethernet adapter Local Area Connection:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
Physical Address. . . . . . . . . : E0-CB-4E-26-BE-94
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Tunnel adapter isatap.{74D5C406-894E-4000-8DE7-6AAEBF7C8382}:
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 Teredo Tunneling Pseudo-Interface:
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
IPv6 Address. . . . . . . . . . . : 2001:0:5ef5:73ba:881:20c1:3f57:fef8(Preferred)
Link-local IPv6 Address . . . . . : fe80::881:20c1:3f57:fef8%14(Preferred)
Default Gateway . . . . . . . . . : ::
NetBIOS over Tcpip. . . . . . . . : Disabled
Solution 1:
There are plenty of cheap 802.11 APs and client cards out there with broken multicast* support, especially when encryption is enabled, and especially especially when WPA2 Mixed Mode (AES-CCMP simultaneously with TKIP) or 802.11i TSN (AES-CCMP and/or TKIP simultaneously with WEP) is enabled.
*Note: In 802.11, broadcast is a subset of multicast: it's a multicast that goes to everyone. So when I say "multicast", think "multicast/broadcast".
On 802.11, multicast is trickier in the AP -> client direction, because it has to be sent at a lowest-common-denominator multicast rate, it isn't ACKed or resent at the 802.11 layer, and if you have WPA or WPA2 encryption on, it has to be sent encrypted with a different key (the group key), and if you have WPA2 Mixed Mode or 802.11i TSN on, it has to be sent not only with a different key, but with a different cipher (a lowest-common-denominator cipher; TKIP in the case of WPA2 Mixed Mode, and WEP in the case of TSN).
One quick way to see if it's just multicast problem is to manually add static ARP entries on each machine, so they know the "IP address -> wireless MAC address" mappings of each other, and then see if you can ping. ARP uses broadcasts, so broken multicasts on an 802.11 network breaks the ability of a wireless client to receive ARP broadcasts when other clients are trying to look up the wireless client's MAC address. Without the ARP mapping, the ping frame can't be addressed at the 802.11 layer, so it can't be transmitted.
If static ARP mappings fixes it, try temporarily turning off all wireless encryption, then delete your static ARP mappings and try your test again. If ARP works this time, it's a sign that multicast is not completely broken on your 802.11 equipment, it's just broken when encryption is on.
About now, some might be asking, "But if broadcasts are broken, why did DHCP work? DHCP uses broadcasts!", and you're right that DHCP uses broadcasts, but in DHCP only the messages from the client to the server are broadcast. In the other direction, they're usually unicast. And it's only in the to the client direction that multicasts are tricky in 802.11.
Check with your AP and client card vendor for firmware and driver updates. Always buy Wi-Fi certified 802.11 gear, because the Wi-Fi certification testing specifically tests to ensure multicast works even when crypto is on. Please also "name and shame" the vendors of the AP and client card(s) in question.
When multicast is broken between an AP and a client, I can't think of an easy way to tell if the fault is with the AP or the client, other than process-of-elimination, by seeing if other brands of wireless clients have the same problem on that AP, and seeing if that wireless client has the same problem on other brands of APs.
The more advanced way to pin the blame on one end or the other is to use another machine that's not part of the test, but has an 802.11 card, to do an 802.11 monitor mode packet trace, starting from before the wireless client associates. Someone well-versed in 802.11 and WPA[2] key handshaking and the like can probably analyze it and find where to point fingers.
I do most of my networking work on Macs, so I can't walk you through getting 802.11 monitor mode packet traces on other platforms, but just in case you have a Snow Leopard (Mac OS X v10.6) box around, you can do:
sudo /usr/libexec/airportd en1 sniff 1
[...run your test...]
^C
...to do an 802.11 monitor mode capture, via en1, which is typically the built-in AirPort card on most Macs, on channel 1. Modify that if your AirPort card is not en1, or if your AP is not on channel 1.
Or you can do:
/System/Library/PrivateFrameworks/Apple80211.framework/Resources/airport -z -c1
sudo tcpdump -I -y IEEE802_11_radio -s0 -w monitorModeTrace.pcap
[...run your test...]
^C
(The -c1 argument to the airport tool puts in the interface on channel 1; modify that to the channel your AP is on.)
Or you can run Wireshark, tshark, etc., but on the Mac you'll still need to use the airport command to set the channel and to force a disassociation.
Solution 2:
Are you certain the firewall on this system is disabled? I've seen this behavior in Windows 7 when it isn't. Otherwise, you could check your arp tables with arp -a to see if you have an entry for 192.168.1.2 at all.
EDIT:
Well, the arp output isn't listing an entry for 192.168.1.2, so your system doesn't appear to even be attempting to contact it. Is there a VPN or other security software involved here? Can you show the output of ipconfig /all?
EDIT2:
Well, I was hoping that ipconfig shouted out something obviously broken, but it doesn't. Can you ping other hosts on the network? Try 192.168.1.1. How about other hosts in the world? My favorite to ping in 4.2.2.2.
EDIT3:
Ok, lets look at things from the other side. Can you do a ping from 192.168.1.2 to 192.168.1.7, then get the results of arp -a, ipconfig /all, and route print on that system?
EDIT4:
As one of the other posters suggests, you should also check your wireless router or access point to make sure it will allow connectivity between clients.
Good luck,
--jed
Solution 3:
It's possible your wireless router is not allowing communication between clients. It's common for wireless routers to deny communication between hosts that are connected to it via the WLAN interface. Some wireless routers have options in their setup program to allow/deny communication between clients.
Solution 4:
I had the same problem today on a NetGear router.
I found out that - God knows why and when - in the Advanced Wireless Settings page (down in the left menu bar, name translated from Italian) the topmost check box WPS Enabled was flagged.
I think I've never actually set that on purpose and anyway I don't think I need it, standing its meaning as per Netgear Support page "What is Wi-Fi Protected Setup (WPS) or NETGEAR's Push 'n' Connect?".
And of course, after clearing that check and saving changes, the ping was working back again. More than that, my laptop's Windows 7 could access again shared folders on the other laptop's Windows 7. That was the main issue that caused this research.
BTW - following @goedson suggestion - it's worth to mention that the router has a so-called PC Isolation feature, which prevents machines on the LAN to see each other. This was turned off since the beginning, I've played with it and anyway it did not make any change.