ESP8266/NodeMCU TCP Test Reveals Issues

Posted by Karl Auerbach /

ESP8266

The ESP8266 is very popular among the maker set as a platform for experimentation in the realm of Internet of Things (IoT).

We have been playing around with the ESP8622 micro-controller running NodeMCU. We’ve been loading simple LUA programs onto the ESP8266 to get familiar with its capabilities.

Now that we’re reasonably familiar with its capabilities, it’s time we put ESP8266/NodeMCU to test.

The 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.

We want to see how ESP8622 micro-controller running NodeMCU would hold up when put under stress.

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
  branch: master
  commit: 98d3b46e2c11068f361154a564ce75a048c9dadc
  SSL: true
  modules: cjson,file,gpio,i2c,mqtt,net,node,rtctime,sntp,tmr,uart,wifi
  build built on: 2016-08-16 20:45
  powered by Lua 5.1.4 on SDK 1.5.4.1(39cb9a32)

The Linux laptop is at address 192.168.100.1 and the ESP8266 at 192.168.100.99.

The Result

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.

Conclusion

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.