odd routing issue

[Elixer]

In windows:

Pinging 192.168.1.32 with 32 bytes of data:
Reply from 192.168.1.39: Destination host unreachable.
Reply from 192.168.1.39: Destination host unreachable.
Reply from 192.168.1.39: Destination host unreachable.
Reply from 192.168.1.39: Destination host unreachable.

In linux:

ping 192.168.1.32
PING 192.168.1.32 (192.168.1.32) 56(84) bytes of data.
From 192.168.1.17 icmp_seq=1 Destination Host Unreachable
From 192.168.1.17 icmp_seq=2 Destination Host Unreachable
From 192.168.1.17 icmp_seq=3 Destination Host Unreachable
From 192.168.1.17 icmp_seq=4 Destination Host Unreachable
From 192.168.1.17 icmp_seq=8 Destination Host Unreachable
From 192.168.1.17 icmp_seq=9 Destination Host Unreachable
...

And finally, from router:

0	192.168.1.32 (192.168.1.32)	64	64	93.18	
1	192.168.1.32 (192.168.1.32)	64	64	67.33	-25.86
2	192.168.1.32 (192.168.1.32)	64	64	77.28	9.95
3	192.168.1.32 (192.168.1.32)	64	64	97.24	19.96
...
Round-Trip: 67.325 min, 88.587 avg, 107.915 max (ms)
   Packets: 5 transmitted, 5 received, 0% lost

Now, the question is why does pinging 192.168.1.32 from linux or windows jump to a IP that isn't 192.168.1.32?
There are no FW rules enabled.
There are no IPTABLES rules to account for what is going on.

192.168.1.32 is a android device hooked up via WiFi.

So, anyone got any ideas?

*edit, looks like 192.168.1.32 isn't showing up in ARP for some reason.
*edit 2. Issue resolved itself.
No idea how, I just went away for a bite to eat, came back, and it was working as it should.

windows:

Pinging 192.168.1.32 with 32 bytes of data:
Reply from 192.168.1.32: bytes=32 time=35ms TTL=64
Reply from 192.168.1.32: bytes=32 time=95ms TTL=64
Reply from 192.168.1.32: bytes=32 time=318ms TTL=64
Reply from 192.168.1.32: bytes=32 time=230ms TTL=64

linux:

PING 192.168.1.32 (192.168.1.32) 56(84) bytes of data.
64 bytes from 192.168.1.32: icmp_seq=1 ttl=64 time=240 ms
64 bytes from 192.168.1.32: icmp_seq=2 ttl=64 time=135 ms
64 bytes from 192.168.1.32: icmp_seq=3 ttl=64 time=363 ms
64 bytes from 192.168.1.32: icmp_seq=4 ttl=64 time=282 ms
64 bytes from 192.168.1.32: icmp_seq=5 ttl=64 time=1.44 ms
64 bytes from 192.168.1.32: icmp_seq=6 ttl=64 time=101 ms
64 bytes from 192.168.1.32: icmp_seq=7 ttl=64 time=328 ms
64 bytes from 192.168.1.32: icmp_seq=8 ttl=64 time=247 ms

And yes, it is showing up in ARP now.

 

[w0ss]

I am guessing those IP's are from the machines you are pinging from. If it can't arp and get a mac address it will show like that.

Perhaps the mobile device shutoff it's wifi since it was in sleep mode.

 

[Emulex]

A router/switch is returning a device unreachable icmp message!

 

[azazel1024]

Probably the mobile device wifi chipset was in a sleep state. Packet coalesscing resulted in a simple ARP request not being returned, so that the linux and windows machines couldn't see it. When the device was awake at some point and ARP requests were going out, both machines finally saw the android device and thus had it listed in their ARP tables.

That is my guess. AFAIK, when you have packet coalesscing on, one of the things the wifi adapter will not do is respond to ARP/broadcasts of any sort and only reply to specificly targeted packets when in a lower power state.

 

[Railgun]

A router/switch is returning a device unreachable icmp message!

In this case, no it's not. That IP isn't (wasn't) in your device's ARP cache. They don't know how to get to it...therefore they're the ones replying.

If you were pinging to something outside of your subnet that wasn't reachable, then your router would reply.