Client cannot see server, despite being on same wifi. What does ping do?

Question

Sometimes, my client cannot reach my server. When it happens, then on my server, I can manually ping the client and now the client can see the server.

My question: What can be done to fix it, without using ping?

I really hope you can help shed light on this sporadic problem. On a bad day it happens up to 5 times. On a good day maybe 1 time. On a really good day there are no problems, but it's rare.

I'm developing on my spare time project that is an iOS app with a c++ server. That is to be made open source at some point.

---

About my setup

Both server and client is on the same wifi.

Both devices can open www.google.com in a browser, so they have internet access.

Server

macOS version 10.11.6 - El Capitan
NGINX version 1.10.0
IP address: 192.168.0.13 (proxy disabled)
The server is not connected to the router via cable.
The NGINX server is running on port 12345 and controls a FastCGI script.

Link to my NGINX configuration and hostname,ifconfig,resolv.

Client

iPad Pro (I'm also experiencing the same problem with my iPhone)
iOS 9.3.5 (13G36)
IP address: 192.168.0.18 (proxy disabled)
The client is not connected to the server via cable.

Router

Netgear CG3000, hardware version 1.04, software version 3.9.21.13.mp3.V1.32.02
I'm experiencing the same problem with other routers, can't remember which ones.

Nothing written to the router event log.

---

Steps to reproduce

I go through these steps.

Step 1: Client unable to reach server

On the client:

In a browser I type in the server IP and port: http://192.168.0.13:12345/status But nothing happens. The client cannot reach the server.

The client can access the internet just fine.

Step 2: Server pinging client - causes things to work

On the server:

I ping the client by its IP address, like this

PROMPT> ping 192.168.0.18
PING 192.168.0.18 (192.168.0.18): 56 data bytes
64 bytes from 192.168.0.18: icmp_seq=0 ttl=64 time=102.210 ms
64 bytes from 192.168.0.18: icmp_seq=1 ttl=64 time=102.966 ms
64 bytes from 192.168.0.18: icmp_seq=2 ttl=64 time=21.176 ms
^C
--- 192.168.0.18 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 21.176/75.451/102.966/38.379 ms
PROMPT>

This ping command causes the client to be able to reach the server. Why does ping make it work?

Step 3: Client can now reach server

On the client:

In a browser I type in the server IP and port: http://192.168.0.13:12345/status Now I get a response from the server. It works.

If I start a proxy and intercept the traffic, then the request/response looks like this:

request

GET /status HTTP/1.1
Host: 192.168.0.13:12345
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPad; CPU OS 9_3_5 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13G36 Safari/601.1
Accept-Language: da-dk
Cache-Control: max-age=0
Connection: keep-alive

response

HTTP/1.1 200 OK
Server: nginx/1.10.0
Date: Sun, 04 Sep 2016 16:11:39 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive

{
    "request_index": 1047,
    "time": "1473005499"
}

Answer 1

ping does an ARP request, which all of the sudden fixes your routing. It will update your ARP table with the MAC address and IP of the server, or client.

Sounds like you may have an IP conflict on your network.

A way to fix it:

• when the problem occurs, issue a arp -a to print the ARP table. Then save a copy of that listing.

• delete the entry for the IP of the server (or client) by issuing: arp -d ipaddress-of-server-or-client

• ping the server (or client)

• issue an arp -acommand again and check what MAC address is now displaying for that IP.

• if it's different, you have an IP conflict somewhere.

Here's a refresher on ARP: https://www.tummy.com/articles/networking-basics-how-arp-works/