Just a short (hopefully not too short) introduction on how "Layer 2" networking works.
Each network device has a MAC address, which is supposed to be unique for every network device ever sold.
Communication between network devices is done based on these MAC addresses. This level of communication we call "layer 2" in the network stack.
A modern network (with switches and access points etc) does not broadcast every packet to every network device, but switches (and APs) do keep track of what MAC address is reachable via what fysical port (on the switch).
So how do we communicate based on IP addresses? IP addressing is not at "layer 2", but at "layer 3".
For every packet you wish to send to another network device and address based on IP address, you need to find out what MAC address has what IP address.
To get this information, a network host does send an ARP packet, which is essentially a question like "Who has 192.168.1.1?"
These ARP packets will be broadcasted over your network in the hope someone will answer "AA:BB:CC:DD:EE:FF has 192.168.1.1"
Since this response is also broadcasted, every switch (and Access Point) does know what port received this answer and thus can update its MAC tables stating what port can be used to reach the host with that MAC address.
The MAC tables of switches are of limited size and also this information can become outdated, so these tables will be cleared every now and then. (interval and protocol for deletion may differ among brands and models)
So it is possible a hop somewhere may no longer know how to route these packets as the MAC address is no longer (or has never been) in its MAC tables.
To fix this, a host may send out a new ARP packet and all is working again.
Now the problem with the ESP devices.
This ARP stuff will only work if ARP requests are being answered.
However the ESP nodes are known to not reply to these ARP requests.
To fight this symptom, I have added a feature in Tools->Advanced (bottom of the page) to send out Gratuituous ARP packets, or in other words answering questions nobody asked.
The ESP will broadcast at a regular interval "AA:BB:CC:DD:EE:FF has 192.168.1.1" and all switches and access points will take note of it by updating their MAC tables.
Apart from not receiving ARP requests every now and then, the ESP may also miss answers to DHCP requests and thus at some point no longer have an IP address.
What does happen in the WiFi part of the ESP is that the core libraries tend to lower power consumption of the ESP by reducing TX power and also increasing the DTIM interval (number of beacon intervals send by the access points to notify a connected client it has new packets waiting) without notifying the access point.
So the AP does not see a reply in due time on a beacon and thus throws away the packet.
What can be done against this?
- Turn off all sleep and eco mode thingies in the ESP settings.
- Send out ping requests continuously from another node to the ESP
- If the AP allows for it increase the timeouts (e.g. MikroTik devices have a "distance" setting which can be set to "outdoor")
- On newer builds, you can increase the
WiFi sensitivity Margin
- Switch to "802.11g" mode
- Set the WiFi channel in the access point to a fixed channel