Update: The issues I had with the ESP8266 SDK Version 1.0 have been fixed with the Version 1.0.1 release dated 24 April 2015. And now, Version 1.1.1 has been released with even more enhancements.
As result I am once again using the EspressIf SDK, my preferred development platform for the ESP8266. It is feature rich, offers low-level control and a very large pool of programming memory space for your application.
The issues I had were corrected with the addition of the mDNS (multicast domain name server) API. This feature has the ESP8266 advertise it’s presence, which has made firmware developed using the SDK and my router accessible from the global internet.
Original post (no longer applicable):
I was very hopeful that the ESP8266, with it’s rich programming environment, would overcome the shortcomings that forced me to abandon the NodeMCU/Lua setup for code development.
After working with the SDK for a couple of weeks (perhaps 60 hours), I was ready to put up the white flag and surrender. This ESP8266 was just too much of a time suck, with no payoff. The SDK also has issues.
Despite the seeming lower level control of the code than the highly abstracted Lua language, I found calls to the compiled SDK core objects that would, for no apparent reason, stop working as expected. Without a clue as to why. The two issues that I could not get a grasp on, and could not find an answer in any on-line sources were:
1. The server stopped responding to “http GET” requests
2. The server will not respond to “http GET” requests without initializing a DNS
Issue1: The server stopped responding to “http GET” requests
I started with the SDK example IoT_Demo. This compiled easily, and soon after flashing it to my ESP8266, I was able to see web browser replies from my “http GET” requests. Great! Or was it?
It did not take long for me to discover two issues. First, I notice that after running some web browser tests for a minute or so, the ESP8266 would suddenly just stop responding to the requests. In order to verify whether the ESP8266 had crashed, I put a print statement out to the serial port periodically with a timer callback. A new message was sent every 2 seconds. What I noticed was that the serial port messages would still occur after the ESP8266 stopped responding. And using Wireshark to monitor network traffic, my router started sending ARP request to the ESP8266 soon after it stopped responding to “http GET” requests.
The ESP8266 did not respond to the ARP queries.
I tried to spoof the ARP response with a packet generator but that did not satisfy the router and the network access remained blocked.
The network connectivity is always restored by resetting the ESP8266. That is probably because the WIFI connection and IP/MAC relationship with the router is established at that time. It seems that there is a timeout period after ESP8266 connection to my WIFI network. After that timeout period, the router wants to renew or refresh it’s ARP cache by sending an ARP request to the ESP8266.
I did set up a DHCP reservation for my ESP8266 in the router, but that did not resolve the problem.
I never did get to the bottom of this and could not find an answer on-line from searches and posing a forum question.
Issue2: The server will not respond to “http GET” requests without initializing a DNS
Determined to find the root cause of the first issue noted above, I dug deep into the exampe IoT_demo code, I found that a DNS was started during initialization. Was that really needed? I did not think so, especially since I wanted to operate in station only mode, not AP mode. But what I found was that if the DNS was not started, the ESP simply would not respond at all to “http GET” requests. After tracing deep into the code, the DNS used was located in China (EspressIf of course!). This made me both uneasy and suspicious. So I changed the DNS to the Google DNS IP (220.127.116.11 and 18.104.22.168). Neither one of those worked!
I am not sure if the server’s failure to respond to requests with starting the DNS was related to the DNS link or something in the callback that periodically (once each 1000 ms) checked the DNS. But this was getting way too complicated for what has been touted as a simple, easy IoT development platform.
With that in mind, I switched development platforms again. This time, to the Arduino IDE version 1.6.1 for ESP8266. This platform did not exhibit any “http GET” drop-outs during a 23 hours stress test.