ESP8266 Developer Zone

I've put together a small web server to act as a control and diagnostics panel on a device controlled by an STM32F407 microcontroller.

I am using the current latest AT command firmware image (2.1.0).

My controller sets up an ESP-01 module as an access point that can take 1 connection with the following commands:
(there may be some transcription errors since this is being pulled out of a C program)



I am using a selection of browsers, phones, and computers to connect to my controller; Mac, iPhone, iPod, Safari, and Chrome, and I'm having issues with a couple of the combinations not receiving the html stream completely.

The web page that I am serving uses the tag:
"<meta http-equiv="refresh" content="5">"
Which causes the web page to be re-requested every 5 seconds. The screen will render properly, every 5 seconds for days, on an iPod Touch using Safari and a Mac using Safari. But on an iPhone 4 with Safari or Mac with Chrome, it will render properly a handful of times and then give a blank screen complaining that the connection was lost.

On the controller to ESP-01 side, the serial conversation looks very clean. No busy errors. I use an oscilloscope with serial decode to show what is being transferred and the timing, and there are no serial issues. The conversation looks like:


I ran Wireshark to take a look at what is happening and the normal conversation looks like:


But when my web pages do not render properly, the conversation looks like:



Talking with a friend who has worked at large networking companies that sound like Risco, he mentioned that a RST can be sent out in reply to data received against a closed connection. That could mean that the ACK for data segment 2 could be received after the connection is closed.

So, I put in a 100mS delay between receiving the "/r/nSEND OK/r/n" message and sending the "AT+CIPCLOSE=0/r/n" command. The problem is reduced a small amount, so I increased the timing to 150mS, but the problem persists.

Instead of waiting for the FIN packet from the PC, the module is sending an RST packet. I hope this makes sense, the information is difficult to describe.

Can anybody shed any light on this?

Thanks,
Andrei Chichak

How about you try to use XAMPP and see if that behaves the same way? That way you can know that your problem is because of something at the phone end and not ESP8266 end.
Also, I would suggest stepping down to SDK v.2.0.0.
The latest version always ensures past issues are fixed, but initial releases are always prone to be buggy.
I cannot replicate the issue here because I do not have the phone and the setup you are using.

I think one of us is confused.

XAMPP is a web server that would run on my PC.

My web server is running on an embedded system that uses the ESP8266 as the TCP/IP layer. The embedded system is very small and resource constrained, so I am using the AT command interface, not writing a stack on the 8266. Therefore, I have ZERO control over the generation of FIN and RST packets. That is 100% generated by the 8266's 2.1.0 firmware.

I have been chasing this issue for about 2 months now. I have worked around most of the weirdness of 2.0.0 and all of the extra /r/n sequences and undocumented extra messages (0,CONNECT and so on). 2.1.0 was my hope of this issue going away without having to resort to using Wireshark and investigating the WiFi side of the conversation.

My interface to the system should be limited to the serial communications. I should only be using the documented interfaces and using the return codes available over the serial port. In this view, instead of just ignoring the returned messages from the 8266, I am parsing them and using the messages to drive my timing.

All of the documentation that I have seen indicates that a RST packet is generated when a message is received when no connection is in place. If the 8266 firmware is returning a SEND OK message, that is my indication that the ACK has been received for the data packet and I should be free to close the connection.

If the SEND OK message is being generated early, before the ACK is received, and I close the connection, then the ACK will be interpreted as being against a non-existent connection and a RST will be generated.

Andrei
(as seen on the embedded.fm podcast and blog)

I suggested XAMPP because I wanted to rule out factors other than ESP8266 causing this issue.
But now that you have confirmed it is the firmware for sure, I will send this topic in to the SDK developers for feedback. It is a very specific issue, thanks for the detailed debug logs. I will get back to you soon.

Thank you for your help with this matter.

If you need a dump out of Wireshark, let me know.

Getting the serial conversation is a little more difficult, as this is an embedded system connected to the module. The sampling of the serial conversation is currently being done with an oscilloscope.

Andrei

If you could get the serial data up on a monitor or just attach some photos of the most relevant parts of the log, it would be great.
Do send me the wireshark logs on
pratik [at] espressif.com
I will patch the issue through to engineers. I do not have access to some confidential sources that drive the radio communication and so there is no way I can help directly with lower, networking level of issues.

I'm just doing some more testing.

I fired up Apache on my Mac (it comes installed, you just have to start it), and Chrome (which always would screw up after about 15 seconds) repeatedly loads my page from a local file using file:, localhost using http:, remote mac running chrome, remote iphone running safari (which screws up even faster), for a couple of hours now.

I have this same file (just with " turned into \" and % changed into %%) compiled into my controller, feeding out the pages, and a iPhone using Safari will stop updating after about 10-15 seconds. The same phone, with the same Safari, will run for hours if the same data is served by Apache running on a Mac.

I figured out how to get the serial stream out of my oscilloscope (though in csv format, whatever). And I'll have to figure out how to get wireshark to capture the same packet when it screws up.

I also noticed that the module will occasionally send out 0,CONNECT/r/n1,CONNECT/r/n before data packets. I have been closing connection 1 when that happens.

The page is set to repost every five seconds. There isn't anything tricky on the page at all. Actually, I'll post it here:

<!DOCTYPE HTML>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="refresh" content="5">
<style type="text/css">
body{
font-size:30pt;
}
h1{
font-size:40pt;text-align:center;
}
p{
font-size:30pt;text-align:left;
}
select,input{
font-size:30pt;
}
input[type=checkbox]{
font-size:30pt;
-moz-transform:scale(2);
-webkit-transform:scale(2);
-o-transform:scale(2);
}
</style>
<title>Flexxaire</title>
</head>
<body>
<h1>CompanyName Controller Diagnostics</h1>
<hr>
<p><strong>Fan pitch: 42.0%
<br>Pitch requested: 17.17%
<br>Pitch Sensor Voltage: 28.9 volts
<br>CAN Status: idle
<br>Error Flags: 00000000
<br><br>Serial Number: 0000000000
<br>Software Version: 17.42
<br>
<br>Controller Running Time: 42 hours
<br>Fan Reversal Count: 17
</strong></p>
<p>Configuration <a href="/">Screen</a>.</p>
<p>Andy <a href="/andy.html">Screen</a>.</p>
</body>
</html>

I'd like to bump this post back into existence.

In the last couple of days I have been revisiting this code and have updated a module to 1.7.4 NONOS to get the AT command set, and my system still shows this exact same issue. With a recent iPhone, my system (ST ARM acting as a web SERVER with an ESP8266 attached via serial using AT commands) will serve the same web page for very long periods (an hour before I got bored).

Apparently with Samsung phones or old iPhones, the data seems to get transferred over the WiFi, then the RST ACK packet resets the browser, but the RST happens much faster.

I have looked at the responses of the AT+CIPSEND or AT+CIPSENDEX commands and they are always SEND OK, even when the link gets reset.

I have inserted delays between receiving SEND OK from CIPSEND, and sending AT+CIPCLOSE=n. I just witnessed a page being sent to the browser, it gets fully rendered before the AT+CIPCLOSE command is sent. The delay between receiving the SEND OK and sending AT+CIPCLOSE is 2 seconds. The issue seems to be with the CIPCLOSE command.

(I just reran the test with a delay of 2500ms between SEND OK and CIPCLOSE. Same result, I can see the full page being rendered and as soon as my printf showing the close being sent happens, the browser resets with the message "Safari cannot open the page because the network connection was lost." The WiFi connection does not reset or drop, and refreshing the screen on the browser restarts the flow of 0,CONNECT +IPD...CIPSEND SEND OK CIPCLOSE...)

Does the latest esp-at have the same issue? https://github.com/espressif/esp-at

I can't easily tell if the latest code still has the issue.

I am using ESP-01/WROOM-02 modules and the latest code switched which pins are used for RX and TX. Since these modules are soldered into circuit boards, a code pin swap is close to fatal. To try the new code I have to install the tool set (to go along with my STM32, MPC5XXX, and PIC tool sets), remap the pins, and start tinkering.

If there are any API changes between 1.7.4 and the latest (new or changed responses to the commands that I'm using), I'll have to alter my state machines to incorporate those changes, then I can check for the issue.

Thanks for your reply...

Andrei