2

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.

network diagram

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?

  • What does the network look like? source and destination IP are needed as well if both use the same router / gateway. This sure looks like a network problem, but let’s define the network a bit more before taking a stab at an answer. – bmike Apr 14 at 17:00
  • Very simple network. Wireless APs and wired devices all feeding into one switch. – Soumya Apr 14 at 17:09
  • Got it - everyone is on the same class C / non-routable network. – bmike Apr 14 at 17:45
  • This post on the apple forums is promising: discussions.apple.com/thread/5896974. Of course now I don't see this problem with any hosts, so ¯_(ツ)_/¯. I guess I did learn from this that there is no well-known issue, so whatever is happening is probably too specific to be answered in a general form. – Soumya Apr 15 at 3:43
  • The problem isn't your arp or routing tables. The issue is your dns cache; try flushing it first. Issue this command sudo killall -HUP mDNSResponder then trying pining by hostname and see if it works. – Allan Apr 18 at 15:45
1

Make sure that your client's route tables have routes that will tell them how to direct traffic for specific IP addresses and blocks of IPs to your default route (router).

You can check like this:

$ netstat -rn -f inet
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.2        UGSc           73   320174     en0
10.3.144.1/32      link#10            UCS             0        0     en0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH             47  5116272     lo0
169.254            link#10            UCS             1        0     en0
169.254.134.80     b8:27:eb:ee:bc:4c  UHLSW           0        0     en0
192.168.1          link#10            UCS             7        0     en0
192.168.1.2/32     link#10            UCS             1        0     en0
192.168.1.2        14:cc:20:d4:56:2a  UHLWIir        27      391     en0   1178
192.168.1.10       0:22:15:91:c1:2d   UHLWI           0       51     en0   1180
192.168.1.66       6c:ad:f8:75:71:6d  UHLWIi          1     1735     en0   1174
192.168.1.81       30:b5:c2:3d:6c:37  UHLWIi          1     1440     en0   1080
192.168.1.85       b8:27:eb:75:c5:c2  UHLWIi          2    21229     en0   1194
192.168.1.87       b8:27:eb:ee:bc:4c  UHLWI           0        0     en0    866
192.168.1.89       34:93:42:2d:92:c4  UHLWI           0       62     en0   1113
192.168.1.91       0:21:bd:af:61:cf   UHLWI           0        0     en0    784
192.168.1.95/32    link#10            UCS             0        0     en0
224.0.0/4          link#10            UmCS            2        0     en0
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI          0     2440     en0
255.255.255.255/32 link#10            UCS             0        0     en0

Here when I ping an IP that wasn't present:

$ ping -c 2 192.168.1.107
PING 192.168.1.107 (192.168.1.107): 56 data bytes
64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.867 ms
64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=7.939 ms

--- 192.168.1.107 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.867/4.903/7.939/3.036 ms

And you'll get a new entry to your route table:

$ netstat -rn -f inet
...
...
192.168.1.107      0:19:d1:e8:4c:95   UHLWI           0        2     en0   1197
...
...

These entries have an expiration time associated as well (far right column).

  • Thanks for the suggestion. I've added the netstat output. Unfortunately after pinging otherhost I don't get an entry with a MAC and expiry, but one with link#5 and ! expiry. Any ideas? – Soumya Apr 14 at 17:04
1

When you "ping" a device (or anytime a device becomes known to another device on your network regardless of how it happens) this creates an entry in the arp table. (arp = address resolution protocol)

You can use arp -a to view the contents of the table.

Capture the contents of the routing table via netstat -rn -f net both prior-to and after pinging the mac from the remote machine. We're looking for routes that have host-specific flags (the capital "H" will appear somewhere in the "Flags" column).

I somewhat suspect that possibly you have an invalid netmask.

It would help if you could provide the contents of your ifconfig en0 output (generically it can be useful to see the configuration of all interfaces, but based on your sample output above, I can see that only en0 and lo0 (the loopback interface) appear to be in use on your mac so there's no point in looking at other interfaces.)

  • 1
    Added the ifconfig output. The netstat flags for target include "H" both before and after pinging mac from target. The difference is that the MAC address is not present until after the incoming ping. arp shows 'at (incomplete)' before, and the MAC address after. I think arp is the problem, because issuing arp -ad lets me reproduce the problem immediately. – Soumya Apr 14 at 18:50
0

This would be typical if the WiFi is also setting up a network. Make sure the WiFi is in bridge mode and letting the main wired router handle DHCP / DNS.

Check that firewalls / routing rules are bidirectional on all devices that aren’t the main router (the main gateway - 192.168.1.2)

You can traceroute to discover if your wireless device has a hop from one or the other.

  • 1
    Good thought, but the wireless APs are definitely not also setting up a network. I see the DHCP leases for all devices (wired and wireless) at the router. Other wired devices can ping the target just fine, only a problem with the mac, and I've never added any special firewall rules for the mac. Added traceroute/path output, but it's also failing from the mac, working from otherhost. – Soumya Apr 14 at 18:00
  • @Soumya we are certainly going to learn something here. Whether it’s a software setting or the wireless router is doing something funky to manage traffic or thinks these are broadcast packets or just not delivering them. – bmike Apr 14 at 18:03
  • It's also not all wireless devices. Some of them can be pinged just fine, even when they're not already in the netstat/arp tables, while others need some ... encouragement first. – Soumya Apr 14 at 18:13
  • @Soumya You might need to diagram out the entire network. If you have a switch - it will be making switch domains. If you can simplify things - no switch or a dumb switch or a hub, that might get you traction. – bmike Apr 14 at 19:56
  • That's a more involved step, but if nothing else works I'll give that a shot. I don't have a hub readily available. Here's a diagram: i.stack.imgur.com/Kpv59.png – Soumya Apr 14 at 20:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .