The WiFi Repeater You Probably Have On Your Bench

Few things are as frustrating as a WiFi signal that drops in and out. On a public network it is bad enough but at home? Even if you can live with it, your cohabitants will certainly impune your technical abilities if they don’t have solid WiFi.  One solution is a WiFi repeater. You can buy one, of course. But you can also make one out of an ESP8266 and some code from GitHub. There is also a video about the project, below.

[Martin Ger’s] code implements NAT, so it isn’t a true WiFi repeater, but more of a bridge or router. Of course, that means performance isn’t stellar, but tests show it can sustain about 5 Mbps, which isn’t bad for a little board that costs a couple of bucks. There is a limit of 8 clients, but that’s more than enough for a lot of cases. Even if you don’t want to use it as a router, it has a mesh mode that could be a basis for some interesting projects all by itself.

There is a web-based configuration for common setup, and a console on port 7777 or the serial port to do advanced things like port mapping or static DHCP addressing. There is a simple firewall and — of particular interest — an MQTT client built-in.

Another neat feature is the optional automesh mode that lets several of the repeaters self-organize. To do this, [Martin] needed a way to know which repeaters were close to the “real” WiFi. When in this mode, the repeaters actually mutate their MAC addresses to provide this information. This is an unusual solution, to say the least. The MAC addresses all start with 24:24 to avoid other devices, but it is odd for a device to dynamically change its MAC address. Or maybe its creative, we couldn’t decide.

If you just want to extend your self-made RS232 network, you can still use an ESP8266. This isn’t, of course, the first ESP8266 we’ve seen substituting for a commercial consumer product.

29 thoughts on “The WiFi Repeater You Probably Have On Your Bench

    1. Definitely repeat on a second channel if you can.

      As well, your throughput would most likely increase if it can be done without NAT. Rewriting packets with NAT is an awful lot of work for that tiny chip. For a quick (well, sort of quick…) example of this, take the oldest router you have collecting dust, connect two machines to it to see how fast the LAN ports are, then move one of the machines to the WWAN port (aka connected via NAT) and see how slow that is. (I’m looking at YOU, my trusty old Linksys WRT54G!)

        1. A good question! They locked down some of it, but not all. Arbitrary unencrypted data packets CAN be transmitted. See “3.5.67. wifi_send_pkt_freedom” at .

          That said, what I was thinking of is a peer-to-peer connection that only allows one device to connect at a time. If the packets are read at the internet layer, it becomes a matter of shuffling incoming packets between wireless connections. If the connecting device is given the same IP address as the ESP chip’s connection to the Wi-Fi AP, the original internet layer packet could be resent unchanged — any reply would be sent to the ESP chip and forwarded back.

          I think the only question is whether the needed single-device peer-to-peer connection can be done. Reading and writing internet layer packets is easy enough. This UDP example is a … good example. :-)

          If this worked, potentially several ESP chips could be chained together wirelessly, with the user’s device connecting to the last in the chain. The whole thing starts to sound like a single user linear “mesh” network… :-)

      1. The LAN ports are also behind the NAT. You can usually only ever have one device NOT behind the NAT, that’s why it exists. Really there’s no reason NAT is needed here, if the SSIDs are different to simplify things the frames can just be bridged between them, assuming there’s access to the frames. If there’s no access to the frames then routing could still be done just configuration past the repeater is probably manual (broken DHCP).

      2. With the closed driver libs on the ESP there is no free access to the L2-Frames, so I found no way to do real L2-repeating. L3-routing without NAT can be done easily, but this requires new dedicated routing entires in the access router – too much manual config for the usual use case.

    2. Hmm. The ESP8266 can successfully push bits at 80Mbps over SPI, but I don’t know how fast it can receive them reliably. There’s also the thing that there is no real DMA for that, you only get a 64-byte FIFO, so that’ll add a small amount of overhead to it.

  1. I’m using a Cisco Linksys EA2700 I picked up at a yard sale for 75 cents. Then I put DDWRT on it so I could use it in place of a TP-Link TL-WR702N that was constantly losing its link to my DSL modem’s WiFi.

    1. I did the same with some cluster software that send raw Ethernet packets. I gave all computers the same MAC: node-id:00:00:00:00:00. I could initialize herders with memset(), It saved a node-ID to MAC lookup table in the code and especially the reverse, which made routing packets very simple,

    1. About 10 years ago, a friend had put 3 yagi wifi antennas on 3 direct tv dishes in his attic. He then ran them into their each wifi card in a pc, used the pc to pack several open hotspots into a single feed that he used in his home.

      This was when most Verizon dsl wifi routers came unprotected from the company, and there were several hundred unsecured hotspots to pull from.

      That guy was a vey early adopter of bittorrent, and he had incredible download speed.

      Of course, the open hotspots dried up eventually, but it was amazing to see 100mbit download speeds in 2007

  2. Very cool project! I have been looking for a small repeater that I can wrap up in a water tight enclosure and run off of solar power to extend our wifi out into our woods. This looks like a good use.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.