What's happening here? Ping

Not quite, your PC is 183, so 183 is saying 224 is unreachable

That looks just plain wrong. What operating system?

Which OS do you think could interpret a failure message as success?

I'm a networking tyro but - unlike some other posters - that seems to me neither wholly surprising nor a failure as such nor something to which Unix and Linux are immune. Search for "ping gives result for a different ip address" and you'll find examples of what can cause it.

Just don't ask me to resolve it :)

yeah, tracrt and nslookup time!

No other OS I know of interprets an ICMP error response as a successful ping response :)

Hint: We're laughing at the summary line, not the host unreachable.

do you have a split subnet? in linux i would want to see your client subnet configuration and default route with 'ifconfig -a' and 'route'. I cant remember the windoze commands.

it LOOKS like your default route is 10.131.97.183, and you are subnetted to some other /25 or so subnet

use C>ipconfig /all and tell us what it sez...

While it does seem an odd way of doing it, there might be some sort of sense to it. Having got a response back that the destination host was unreachable does mean that the packets were not lost, just that they could not be passed on, unlike if there were just no response and each attempt timed out.

Fair enough if I have been wrong in interrupting that as (to paraphrase) no more than "I counted 4 packets out and I counted 4 replies, so none were lost" - ie nothing about which if any address was reached.

It's a perfectly normal windows message,

.183 is the machine doing the pinging of the .224 machine, the 183 machine is reporting that the 224 machine is not reachable, it's different from "no reply".

tracert won't help much as both addrs are on the same subnet (assuming typical /24 masks) and if you can't ping by numeric addr, then DNS doesn't enter into it.

It's .224 which is unreachable, and it is .183 which is telling you so. The 'unreachable' messages wouldn't be counted as replies (just as error messages) by any sensible operating system and the summary should stay 100% loss.

Wonder if something is stuck in the ARP cache.

Try: arp -d *

(at elevated command prompt)

Unfortunately it might be as simple as the local connection saying 'I am not on the same network as the destination'