The ESP8266 is very popular among the maker set as a platform for experimentation in the realm of Internet of Things (IoT).
Now that we’re reasonably familiar with its capabilities, it’s time we put ESP8266/NodeMCU to test.
One of our first little programs was one that caused the ESP8266 to join one of our test wi-fi nets and offer a simple web server that would blink the LEDs on command from a web page.
Test Environment: The Lab Setup
We have a simple test rig that uses a detached IPv4 subnet. We attach a Linux laptop to this subnet via a wired connection to a wifi-fi access point (i.e. a simple bridge not doing NAT or routing or filtering). The ESP8622 was programmed to join this wi-fi net, establish a static IPv4 address, and initiate a web server.
Being the network techies that we are we fired up Wireshark to spy on the traffic going back and forth.
We set up a simple test script on the laptop to do a sequence of HTTP HEAD operations. We started with an interval of one second and then moved to 0.2 second gaps.
For each of these operations the Linux laptop would open a new TCP connection to the ESP8266/NodeMCU widget, send the HTTP operation, wait for the response, and then close the TCP connection.
Test Environment: Technical Details
By-the-way, here is the relevant version information:
- Linux: 4.7.3-200.fc24.x86_64 #1 SMP Wed Sep 7 17:31:21 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
- NodeMCU: NodeMCU custom build by frightanic.com
build built on: 2016-08-16 20:45
powered by Lua 5.1.4 on SDK 188.8.131.52(39cb9a32)
The Linux laptop is at address 192.168.100.1 and the ESP8266 at 192.168.100.99.
What we saw was surprising.
At first things seemed to run along smoothly. Then after a few iterations the ESP8266/NodeMCU began stumbling when operation was finished and the connection was closed.
When the ESP8266/NodeMCU web server had finished sending the requested data it quite reasonably closed the TCP connection. TCP connections, however, do not fully close until both ends close the connection. This is where things went awry.
You can see this duel in the first Wireshark screenshot below.
After we stopped the Linux script, the triggering HTTP operations (and their supporting TCP connections) ceased, but the duel between Linux and the ESP8266/NodeMCU continued. You can see that in the second screenshot.
The ESP8266/NodeMCU’s TCP stack does not interact well with the Linux TCP stack when closing TCP connections. This is something that should be examined by Espressif (the manufacturer of the ESP8266) or the NodeMCU group.
This problem does not seem to appear under light loads or infrequent TCP connections. But if one is using the ESP8266 in a RESTFull system in which TCP/HTTP connections are frequently made and frequently closed then this problem could consume processing, memory, and network resources. For the typical Linux system those resources are plentiful. But on the typical ESP8266 these resources are often limited. If carried to the extreme one could anticipate that the ESP8266 could become so buried with the handling of half-closed connections that it becomes unable to do the work it was programmed to do.