ESP8266 Community Forum

- Sun Nov 19, 2017 8:51 am #71939 Sometimes one might want to use several ESPs in a row or a mesh to cover a larger distance or area. Generally, this can be done without major problems with the esp_wifi_repeater. Actually, you will have several layers of NAT. Of course, the available bandwidth goes down the more hops you need. But uses have reported that even 5 esp_wifi_repeaters in a row work quite well.

In such a setup configuration is quit a time consuming and error-prone activity. To simplify that, I would like to propose a kind of a protocol that automates and simplifies this for an ESP with NAT-routing in place: "Automesh":

Just configure the SSID and the password and do the following: Each ESP should automatically offer a WiFi network on the AP inferface with the same SSID/password as it is connected to. Clients can use the same WiFi settings for the original network or the repeated ones. Each ESP will first search for the best other AP to connect to. This is the one which closest to the original WiFi network and has the best signal strength (RSSI).

The signal strenght is easy to measure with a scan, but which is the one closest to the original WiFi network if you see several APs with the same SSID? Therefore I use a somewhat dirty trick: the esp_wifi_repeaters in "automesh" mode manipulate their BSSID, i.e. the MAC address of their AP interface which is send out with every beacon frame 10 about time times per second. It uses the format: 24:24:mm:rr:rr:rr. "24:24" is just the unique identifier of a repeater (there is a minimal probability that this collides with the real APs MAC, but we can neglect this, as we can change that prefix if really required). "mm" means the "mesh level", this is the distance in hops to the original WiFi network. The last three "rr:rr:rr" are just random numbers to distinguish the various ESPs.

Now each ESP can learn which other ESP is the closest to the the original WiFi network, can connect to that, and chose its own BSSID accordingly. This creates a tree (a very special mesh) with the original WiFi network as root and nodes on several mesh levels (actually, it works somewhat similar as the Spanning Tree Protocol (STP) on the link layer or routing on the network layer using a Distance Vector protocol). As soon as a link loss is detected, configuration is restarted. This should avoid loops as during (re-)configuration also no beacons with an BSSID are sent.

The latest version of the esp_wifi_repeater includes this feature - give it a try!

- Thu Nov 23, 2017 7:33 pm #72025 Woohoo thats really fantastic! Thank you! Have to try it on the weekend.

One question, if a device is connected to one of the esp's and changes its place, will it automaticly switch to another esp with better connection or will it stay on this one esp till the connection is lost and then just search if there is a known network around, finding an esp with better connection and reconnecting, so with total loss of the connection when switching? Or does it behave like networks in public places like universitys with multiple accespoints where the ap's will be switched but the user doesnt even recognize it?

- Fri Nov 24, 2017 2:01 am #72030 AP selection in a WiFi network is done by the client. I.e. the client decides which AP to use and when to switch over to another (in some drivers the "stickyness" of a client is a parameter). In new centrally managed network the APs can enforce such a switch by kicking out an associated client until it selects the "right" AP, but this is not done here.

Client connections will break after AP change: as the "esp_wifi_repeater" is in fact a layer 3 IP NAT router, each AP spans its own IP subnet, i.e. a client gets a new IP address after a switch. I would love to build a real layer 2 switching, but the ESPs driver doesn´t allow for that.

- Fri Nov 24, 2017 3:55 pm #72054 Thanks for explaining that, but anyway its a realy cool feature