Mac – Why the different results for ping? Or why is the Time Capsule getting involved

mac-minipingssh

I'm setting up a bash script network monitor at the core of which I am using ping.

When a host is down, I get the standard host is unreachable, usually.

But on one box it seems to be getting a redirected ping which I can't understand.

My Network:

  • I'm on an MBP runnning 10.11 (ElCapitan).
  • The network in this case is all wired.
  • IP addresses are all assigned from Fritz!Box.
  • Switches are unmanaged.
  • Time capsule has Wi-Fi turned off (I utilise Wi-Fi from Fritz!Box).
  • I've shortened the ping count below purely for brevity.

Network map:

MBP IP:192.168.178.45
 |
 |
SWITCH#1 ---- Fritz.box (DHCP/Internet) ---- ISP
 |   \         192.168.178.1
 |    \
 |     \ dav3tc (Apple Time Capsule)
 |      \__  192.168.178.29
 |
SWITCH#2
 |  \
 |   \
 |    \ wwwelc (Mac mini running 10.11 but turned off)
 |     \___  192.168.178.80
 \
  \  Ubuntu
   \__ 192.168.178.28

Both machines (we'll call wwwelc and Ubuntu) are in a shutdown state* with WoL active (except the Mac mini isn't starting up yet—to be determined why at a later time).

Edit: It turns out the Mac mini was only in a sleep state, which is worse since it wasn't waking up at all… subject of a different although possibly related question

From the MBP I am getting two different unreachable responses. Run from the same computer (the MBP) and in the same Terminal session/screen:

MBP > Ubuntu

MBP:~ madivad$ ping -c 3 -W 1 192.168.178.28
PING 192.168.178.28 (192.168.178.28): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1

--- 192.168.178.28 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

MBP > wwelc

MBP:~ madivad$ ping -c 3 -W 1 192.168.178.80
PING 192.168.178.80 (192.168.178.80): 56 data bytes
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 1c50   0 0000  40  01 788a 192.168.178.45  192.168.178.80

Request timeout for icmp_seq 0
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 8ff4   0 0000  40  01 04e6 192.168.178.45  192.168.178.80

Request timeout for icmp_seq 1
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 bda5   0 0000  40  01 d734 192.168.178.45  192.168.178.80


--- 192.168.178.80 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Both are replying with the expected Request timeout for icmp_seq and in many packets you sometimes also see ping: sendto: Host is down.

I sometimes get a similar diversion appearing when the system is up, but I'm having trouble replicating it now. To fix it at the time I just took the ethernet port down and brought it back up again:

sudo ifconfig en0 down && sudo ifconfig en0 up && exit

I was running this from SSH and without the exit it would lock my remote Terminal session 🙂

Here is a copy of ping results as I shutdown the wwwelc:

64 bytes from 192.168.178.80: icmp_seq=1273 ttl=64 time=0.674 ms
64 bytes from 192.168.178.80: icmp_seq=1274 ttl=64 time=0.528 ms
64 bytes from 192.168.178.80: icmp_seq=1275 ttl=64 time=0.636 ms
64 bytes from 192.168.178.80: icmp_seq=1276 ttl=64 time=0.715 ms
Request timeout for icmp_seq 1277
Request timeout for icmp_seq 1278
Request timeout for icmp_seq 1279
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 4506   0 0000  40  01 4fd4 192.168.178.45  192.168.178.80

Request timeout for icmp_seq 1280
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 aaae   0 0000  40  01 ea2b 192.168.178.45  192.168.178.80

As we can see, the Time Machine is getting involved again.

Power cycle Time Machine

you can see when the Time Machine is unplugged:

Request timeout for icmp_seq 1462
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 cb5d   0 0000  40  01 c97c 192.168.178.45  192.168.178.80

Request timeout for icmp_seq 1463
Request timeout for icmp_seq 1464
Request timeout for icmp_seq 1465
Request timeout for icmp_seq 1466

I then plugged the Time Machine back in and allowed it time to boot. My pings to wwelc stayed succinct. I woke it from sleep (I managed to get it to wake using Magic Packet), logged in by SSH and sent it back to sleep (yeah, I'm nasty—wake up, go back to sleep, wake up, go back to sleep):)

I thought it was going to be all good, but eventually I saw this (pings timing out once it sleeps):

64 bytes from 192.168.178.80: icmp_seq=1670 ttl=64 time=0.617 ms
64 bytes from 192.168.178.80: icmp_seq=1671 ttl=64 time=0.588 ms
64 bytes from 192.168.178.80: icmp_seq=1672 ttl=64 time=0.493 ms
64 bytes from 192.168.178.80: icmp_seq=1673 ttl=64 time=0.690 ms
Request timeout for icmp_seq 1674
Request timeout for icmp_seq 1675
Request timeout for icmp_seq 1676
Request timeout for icmp_seq 1677
Request timeout for icmp_seq 1678
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 f5fb   0 0000  40  01 9ede 192.168.178.45  192.168.178.80

Request timeout for icmp_seq 1679
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 a2db   0 0000  40  01 f1fe 192.168.178.45  192.168.178.80

Request timeout for icmp_seq 1680
36 bytes from dav3tc.fritz.box (192.168.178.29): Redirect Host(New addr: 192.168.178.80)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 41f4   0 0000  40  01 52e6 192.168.178.45  192.168.178.80

I have once again gone through the Time Machine settings and cannot see where, how, or why it is intervening in the ping. Wi-Fi in both units are turned off.

Here is a ping going to another Mac mini:

MBP:~ madivad$ ping 192.168.178.26
PING 192.168.178.26 (192.168.178.26): 56 data bytes
64 bytes from 192.168.178.26: icmp_seq=0 ttl=64 time=66.294 ms
64 bytes from 192.168.178.26: icmp_seq=1 ttl=64 time=2.006 ms
64 bytes from 192.168.178.26: icmp_seq=2 ttl=64 time=1.665 ms
64 bytes from 192.168.178.26: icmp_seq=3 ttl=64 time=20.826 ms

TLDR;

For some reason pinging a Mac mini (wwwelc) from my MBP goes via the time machine when the Mac mini is unreachable.

  • The Time Machine is not set up as a Time Machine (it is only acting as a file server).
  • Wi-Fi in both units is off.
  • Time Machine has all wireless features disabled.
  • DHCP is not served by Time Machine, but from the router instead.
  • The Time Machine does not intervene in any other ping, just this one.

Any ideas?

Best Answer

There's really nothing to worry about - what you're seeing are ICMP redirects, and they are not a problem as such.

The reasoning behind what you're seeing is this:

Your MBP usually has the MAC address of wwwelc in its ARP cache. Similarly, SWITCH1 and SWITCH2 knows on which of their ports the computer with the MAC-address of wwwelc is connected. This means that it can send IP packets directly to the MAC address of wwwelc.

When you power off the Mac Mini and some time passes, the MAC address will eventually be flushed from the caches on your switches and/or the ARP cache on the MBP.

Imagine that it is no longer in the cache on the switch. This means that the switch has no choice than to broadcast packets for that MAC-address to all its ports. This means the SWITCH1 will send the packet to both the Time Capsule as well as SWITCH2.

The Time Capsule receives the packet and acts as a router. It will try to route the packet to its destination. It finds that the packet is actually destined for something on the ethernet connection on which it came into the Time Capsule - i.e. it is not to be routed out with the WiFi or Internet connection ports.

For that situation, we have something called ICMP redirects. It is common to many routers from various producers - so it's not Time Capsule specific.

The Time Capsule sends out the ICMP redirect to be "nice". It is letting the sender know that it received a packet where the sender could actually have sent it directly to the next hop of the route without involving the Time Capsule. So it is letting it know that it could have saved a hop.

I.e. the following conditions are met:

  • The packet came in on the same port that it is going to be routed out of

  • The network (subnet) of the source IP is the same network as the next hop (i.e. the sender could just have sent it directly to that next-hop)

  • The packet is not source routed (i.e. the sender did not instruct a specific path to be taken)

So that's the explanation for what you're seeing. The Time Capsule receives the packet because the SWITCH or MBP doesn't know where to send the packet - so it broadcasts it. The Time Capsule is trying to be nice, saying that the packet could have been delivered in an easier way. And finally, the destination wwwelc is still down, so you're not going to get any replies from the destination of course.

Related Question