Mesh Network over 5ha Area

[lnetwalker]

i want to build a mesh network over an area of 5ha (50000sm). Is ist possible to do that with the esp32_nat_router? I want to use it for telefony over internet (only one concurrent connection) and some IoT sensors using wifi. Longest distance is 300m. So I guess I need to chain the esp stations. Do you think it's possible to do that. Any recommendations on this? Every Node will be powered by a solar panel and a battery for the night. Has anybody tried that before and can share his learnings? Does it work to NAT a NAT network (or even more hops more NAT) and reach hosts in the core network, like HomeAssistant?

THX 4 any idea

[martin-ger]

TL;DR: IoT is feasible, VoIP is a challenge.
The closest prior art is the Autotree approach described and implemented as AutoMesh mode
in the older esp_wifi_repeater (ESP8266) project. That system was designed for such an scenario.

The current esp32_nat_router (ESP32) does not have AutoMesh yet, but you can replicate its
subnet scheme manually — and the ESP32 gives you more RAM, faster CPU, WireGuard, and
better throughput.

Despite the word "mesh," what works reliably here is a spanning tree: one root AP
(your internet uplink), with repeater nodes branching outward hop by hop. True mesh
(where every node can reach every other node directly) requires a dedicated mesh
protocol (e.g., ESP-MESH / painlessMesh) that operates below IP and is incompatible
with standard WiFi clients. The NAT router approach builds a tree — and for your
use case (IoT sensors + VoIP, linear coverage over fields), a tree is exactly what
you want.

The esp_wifi_repeater project includes a protocol that runs entirely on ESP8266
to automatically form a rooted tree of NAT routers with zero manual configuration per node:

• All nodes share the same SSID and password for both their STA (uplink) and AP
  (downlink) interfaces.
• Each node encodes its hop distance from the root (mesh level) in its AP BSSID:
  24:24:mm:rr:rr:rr — the prefix 24:24 identifies a repeater node, mm is the
  mesh level, rr:rr:rr is random per device.
• Subnet addressing follows 10.24.m.0/24 where m is the mesh level, so the
  root AP is at level 0 (its own network), hop-1 nodes serve 10.24.1.0/24,
  hop-2 nodes serve 10.24.2.0/24, and so on.
• Tree formation uses a distance-vector-like election: each node scans for APs
  with the configured SSID, picks the one with the lowest mesh level and acceptable
  signal (above am_threshold, default −85 dBm), and connects there. This gives
  shortest-path-to-root with a signal quality floor.

AutoMesh is not yet implemented in esp32_nat_router. The ESP8266 firmware
diverged from the ESP32 codebase years ago. If this is important to you, a port is
feasible: the BSSID manipulation, subnet assignment, and scan/election logic are all
in the ESP8266 source and the concepts map cleanly onto the ESP32 esp_wifi API.

Without AutoMesh you configure each node individually, but you can follow the same
10.24.m.0/24 addressing scheme to keep things organised and debuggable.

Why unique subnets are mandatory?

The firmware defaults every AP to 192.168.4.1/24 (DEFAULT_AP_IP in
include/wifi_config.h). If two adjacent nodes share this subnet:

• Node N's STA interface gets 192.168.4.x from node N−1's DHCP.
• Node N's AP is also 192.168.4.0/24.
• The kernel routing table has two routes for the same prefix — one via AP, one via
  STA. Behavior is undefined; in practice NAT (ip_napt_enable(my_ap_ip, 1))
  cannot distinguish inside from outside and traffic breaks.

Every node must have a different AP subnet. Set it once before deployment:

set_ap_ip 10.24.1.1     # on node 1
set_ap_ip 10.24.2.1     # on node 2
set_ap_ip 10.24.3.1     # on node 3
restart

Standard ESP32 modules (PCB/chip antenna) realistically cover 50–150 m outdoors.
For 300 m you need:

• External antenna variants: ESP32-WROOM-DA (dual antenna diversity), or any
  board with a U.FL/SMA connector.
• High-gain antennas at both ends of the long link: 5–9 dBi omni or a directional
  Yagi/panel if the link is point-to-point.
• Clear line of sight. Fresnel zone clearance matters at 300 m — the first Fresnel
  zone radius at mid-path is ~7 m at 2.4 GHz over 300 m, so vegetation or terrain
  at that height degrades the link substantially.

For 5 ha arranged roughly as a strip or polygon, 3–5 nodes at 150–200 m spacing is
more reliable than pushing 300 m links.

Traffic direction	Works?	How
Sensor → internet / HA MQTT	Yes	Outbound TCP through all NAT layers; no config needed
Sensor → HA HTTP	Yes	Same — outbound connection
HA → sensor (push/direct)	No	HA cannot initiate inbound through chained NAT
HA mDNS discovery of sensors	No	mDNS does not cross NAT boundaries
Ping/traceroute across full chain	Limited	Each NAT layer hides the next subnet

The practical solution for HA integration is MQTT. Sensors publish to the HA
MQTT broker (outbound persistent TCP from each sensor). HA subscribes and commands
devices by publishing back. This punches through any number of NAT layers with zero
port forwarding.

VoIP needs only ~64–128 Kbps, within the chained ESP32's throughput.
The concern is SIP NAT traversal, not bandwidth. For VoIP over
NAT, you will need at minimum a SIP proxy. I have no experience with multiple layers
of NAT here.

[lnetwalker]

TL;DR: Your answer is exactly so impressive than your code - thx a lot for your detailed answer!

As I have lot's of different boards here ( both ESP32 and ESP8266 ) I will start experimenting with both to see how both solutions work and to check which variant is the best for my setup.

I will share my efforts here so that others can take advantage of my experiments.

Again many thanks