My network looks like this and I have all sorts of devices: android phones, tablets, raspberry pis, some of which my Mac can’t ping over WiFi.
Other devices on the network can ping the target just fine. In one case, I could even use ssh -L 2222:target:22 other-device -N; ssh localhost -p 2222 ping mac, and was then able to ssh to the target from the mac directly.
Targets do not respond to any connections from the mac (ping, ssh, http). Not a sleeping NIC problem on the targets because other devices can communicate with the targets just fine (on all the same protocols).
Mac is plugged in to ethernet, targets are wirelessly connected to the same network (no guest mode, vlan, etc., but there might be other options I haven't considered). However other-device in the instance above is also hardwired.
Edited to add network information:
- targets are connected to a wireless AP which is connected to the main switch.
- mac is connected to a switch which is connected to the main switch.
- otherhost is connected to the main switch
- main switch is the only LAN device connected to the router (the other device is the WAN cable modem)
Edited to add more information:
Ping from mac:
ping target
PING target.domain (192.168.1.126): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
ping: sendto: No route to host
Request timeout for icmp_seq 2
ping: sendto: Host is down
Request timeout for icmp_seq 3
ping: sendto: Host is down
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
ping: sendto: Host is down
Request timeout for icmp_seq 6
^C
--- target.domain ping statistics ---
8 packets transmitted, 0 packets received, 100.0% packet loss
Ping from otherhost:
ssh otherhost
ping target
PING target.domain (192.168.1.126) 56(84) bytes of data.
64 bytes from target.domain (192.168.1.126): icmp_seq=1 ttl=64 time=46.1 ms
64 bytes from target.domain (192.168.1.126): icmp_seq=2 ttl=64 time=70.2 ms
64 bytes from target.domain (192.168.1.126): icmp_seq=3 ttl=64 time=95.8 ms
64 bytes from target.domain (192.168.1.126): icmp_seq=4 ttl=64 time=118 ms
64 bytes from target.domain (192.168.1.126): icmp_seq=5 ttl=64 time=38.6 ms
^C
--- target.domain ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 38.572/73.770/118.162/29.918 ms
netstat on mac: (thanks @slm)
netstat -rn -f inet
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.1 UGSc 222 0 en0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 20 1512 lo0
169.254 link#5 UCS 0 0 en0 !
192.168.1 link#5 UCS 14 0 en0 !
192.168.1.1/32 link#5 UCS 1 0 en0 !
192.168.1.1 78:8a:20:xx:xx:xx UHLWIir 167 954 en0 1183
192.168.1.7 0:1e:6:xx:xx:xx UHLWIi 1 43 en0 1149
192.168.1.59/32 link#5 UCS 0 0 en0 !
...
192.168.1.126 link#5 UHLWI 0 13 en0 !
...
192.168.1.186 9c:8e:cd:xx:xx:xx UHLWI 0 0 en0 1180
...
192.168.1.255 ff:ff:ff:ff:ff:ff UHLWbI 0 15 en0 !
224.0.0/4 link#5 UmCS 1 0 en0 !
224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0
255.255.255.255/32 link#5 UCS 1 0 en0 !
255.255.255.255 ff:ff:ff:ff:ff:ff UHLWbI 0 7 en0 !
It looks like something is weird in the routing table. For otherhost (.7), there is a MAC address and expiry time, but for target there is only link#5 and an ! in expiry. (The flags also differ a bit, but there are other entries with the same flags that do include a MAC address and expiry, so I'm not sure that's relevant.)
traceroute from mac:
traceroute target
traceroute to target.domain (192.168.1.126), 64 hops max, 52 byte packets
1 * *traceroute: sendto: No route to host
traceroute: wrote target.domain 52 chars, ret=-1
*
traceroute: sendto: Host is down
2 traceroute: wrote target.domain 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote target.domain 52 chars, ret=-1
*traceroute: sendto: Host is down
traceroute: wrote target.domain 52 chars, ret=-1
tracepath from otherhost (wired, but linux):
tracepath target
1?: [LOCALHOST] pmtu 1500
1: target.domain 5.742ms reached
1: target.domain 3.304ms reached
Resume: pmtu 1500 hops 1 back 1
netstat after pinging mac from target:
...
192.168.1.126 64:a2:f9:xx:xx:xx UHLWI 0 9 en0 1133
...
traceroute after pinging mac from target:
traceroute target
traceroute to target.domain (192.168.1.126), 64 hops max, 52 byte packets
1 target.domain (192.168.1.126) 5.718 ms 3.204 ms 3.538 ms
ifconfig en0 on mac:
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
ether 38:c9:86:xx:xx:xx
inet6 fe80::xx...xx%en0 prefixlen 64 secured scopeid 0x5
inet6 2601:xx...xx prefixlen 64 autoconf secured
inet6 2601:xx...xx prefixlen 64 autoconf temporary
inet 192.168.1.59 netmask 0xffffff00 broadcast 192.168.1.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (1000baseT <full-duplex>)
status: active
Edit: Looks like the problem lies in the ARP table on mac.
arp -a during the problem:
target.domain (192.168.1.126) at (incomplete) on en0 ifscope [ethernet]
arp -a after pinging mac from target:
target.domain (192.168.1.126) at 64:a2:f9:xx:xx:xx on en0 ifscope [ethernet]
sudo arp -ad immediately reverts to the broken state, and requires a fresh ping from target.
How can I make sure the ARP table is built correctly?
(Restarting doesn't seem to help, all of the output above is from a fresh boot, up 31 mins)
Is there some ARP filtering built into mac, or some form of broadcast listening that needs to be enabled in macOS?
sudo killall -HUP mDNSResponderthen trying pining by hostname and see if it works.