Odd Wifi client behaviour

[PaulCa]

So I was putting together a Wifi switch, a SOnOff switch. Basically it's a mains switch with Wifi so you can turn it on and off.

Anyway it works. I managed to hack it to get it connecting to my Wifi and a static IP. This was after their own stupid mobile app failed to work with the device at all. It's just an ESP8285 microcontroller, so I just flashed it with custom firmware to create a very basic REST API.

So hitting it with http://10.0.0.4/status from my Windows PC (Wired LAN) and it answers fine.
Hitting it from my Linux server 10.0.0.199 also wired and I get "No route to host".
Hitting it from the Raspberry PI 10.0.0.3, also wired and I get "No route to host".

Checking and the ARP table has <incomplete> for the device IP 10.0.0.4.

So, for some reason the access point (TPLink Archer VR900) has allowed/answered the ARP request for the Windows PC, but not for the Linux machines.

I have never seen this before.

Any ideas?

UPDATE: I rebooted the device and it's now accessible from my server, but still not from the raspberry PI.

Something fishy if going on with the ARP forwarding through the TPLink from Wifi to LAN.

 

[PaulCa]

Grrr... it just started working. For some reason the ARP entry didn't appear for 5 minute! Still something is a bit messed up.

 

[PaulCa]

tldr; If you are having this issue with ESP devices, make the device ping itself a few times a minute.

Ok, just in case someone stumbles across this thread with a similar problem, some of the ESP8266 and ESP32s seem to have an issue where ARP only works at boot. Some it only works for a longer period of time. Some wake up and ARP sporadically. It relates to the various sleeping modes. If it's got firmware that puts it into deep modem sleep it will ONLY wake up and enable it's Wifi stack when the device sends something. It is completely deaf to outside traffic when in this sleep mode.

The weirdest thing was the solution which came from "fiddling around". I added a "ping" service to the REST api on the device that would take an IP and have the ESP ping it. I figured if the ESP could contact a host, then the ARP would resolve and they could talk. Turns out that doesn't work. I don't think a reply in TCP/IP requires ARP to function, the reply path is known to the stack from the incoming packet.

What did work, was an accident. I got the device to ping itself. Suddenly anything waiting on an ARP reply from it it, got one.

So I just run this on a timer to fire every 20 seconds and ping itself. Now they are contactable reliably.