[httpUpdate] Update.writeStream failed! (ERROR[6]: Stream Read Timeout)

[scottfuhrman]

Using the latest from Git, downloaded this morning.

Trying to do a http update, I always receive the error below. This is with using the example PHP script on the web server. When I fetch the file directly (not using the PHP server-side script), it works fine.

[httpUpdate] Update.writeStream failed! (ERROR[6]: Stream Read Timeout)

Confirmed I have 4M flash, tried using Arduino IDE 1.6.7 and 1.6.8 (nightly). Same result.

Debug output below:

1264, room 16 tail 0 chksum Booting...

Connecting to XXXXXX wifi evt: 0 wifi evt: 3

WiFi connected. [HTTP-Client][begin] host: XXXXXX port:80 url: /esp8266/upgrade_check.php https: 0 httpsFingerprint: [HTTP-Client] connect http... [hostByName] request IP for: XXXXXX [hostByName] Host: XXXXXX IP: xx.xx.xx.xx [HTTP-Client] connected to XXXXXX:80 [HTTP-Client][handleHeaderResponse] RX: 'HTTP/1.1 200 OK' [HTTP-Client][handleHeaderResponse] RX: 'Date: Wed, 24 Feb 2016 16:27:29 GMT' [HTTP-Client][handleHeaderResponse] RX: 'Server: Apache' [HTTP-Client][handleHeaderResponse] RX: 'Content-Disposition: attachment; filename=prod_code.bin' [HTTP-Client][handleHeaderResponse] RX: 'x-MD5: 64d43986a1e128adf07350b67441a6aa' [HTTP-Client][handleHeaderResponse] RX: 'Content-Length: 208016' [HTTP-Client][handleHeaderResponse] RX: 'MS-Author-Via: DAV' [HTTP-Client][handleHeaderResponse] RX: 'Connection: close' [HTTP-Client][handleHeaderResponse] RX: 'Content-Type: application/octet-stream' [HTTP-Client][handleHeaderResponse] RX: '' [HTTP-Client][handleHeaderResponse] code: 200 [HTTP-Client][handleHeaderResponse] size: 208016 [httpUpdate] Header read fin. [httpUpdate] Server header: [httpUpdate] - code: 200 [httpUpdate] - len: 208016 [httpUpdate] - MD5: 64d43986a1e128adf07350b67441a6aa [httpUpdate] ESP8266 info: [httpUpdate] - free Space: 749568 [httpUpdate] - current Sketch Size: 296276 [httpUpdate] - current version: 1.1 [httpUpdate] runUpdate flash... [begin] roundedSize: 0x00033000 (208896) [begin] updateEndAddress: 0x00100000 (1048576) [begin] currentSketchSize: 0x00049000 (299008) [begin] _startAddress: 0x000CD000 (839680) [begin] _currentAddress: 0x000CD000 (839680) [begin] _size: 0x00032C90 (208016) ERROR[6]: Stream Read Timeout [httpUpdate] Update.writeStream failed! (ERROR[6]: Stream Read Timeout) [httpUpdate] Update failed [HTTP-Client][end] tcp is closed HTTP_UPDATE_FAILD Error (6): Update error: ERROR[6]: Stream Read Timeout

Any ideas?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Links2004]

do your server have some sort of buffering the output of the php script? or is the execution slow? can you tried a other server, this may helps to point down where the problem is coming from.

[scottfuhrman]

I am uncertain of any buffering, when I download the bin file via the PHP script in a normal web browser it works fine and is fast. I will try an internal server on my LAN to see if there is a difference.

[scottfuhrman]

OK I tried tonight to to a OTA http upgrade but placed the PHP script and bin file on a server in my local LAN. Worked fine.

Before I was trying to do the same with my webhost's server, which I believe to be a more reasonable use case as it is very beneficial to update code from "the cloud" as opposed to a local server for many people. Now that it has been determined that there is a difference between the two, what can I do to figure out how to address the problem?

Connecting to XXSSIDXXX wifi evt: 0 wifi evt: 3

WiFi connected. [HTTP-Client][begin] host: 192.168.0.157 port:80 url: /upgrade_check.php https: 0 httpsFingerprint: [HTTP-Client] connect http... [hostByName] Host: 192.168.0.157 is a IP! [HTTP-Client] connected to 192.168.0.157:80 [HTTP-Client][handleHeaderResponse] RX: 'HTTP/1.0 200 OK' [HTTP-Client][handleHeaderResponse] RX: 'Date: Thu, 25 Feb 2016 03:26:30 GMT' [HTTP-Client][handleHeaderResponse] RX: 'Server: Apache/2.4.7 (Ubuntu)' [HTTP-Client][handleHeaderResponse] RX: 'X-Powered-By: PHP/5.5.9-1ubuntu4.14' [HTTP-Client][handleHeaderResponse] RX: 'Content-Disposition: attachment; filename=prod_code.bin' [HTTP-Client][handleHeaderResponse] RX: 'Content-Length: 208016' [HTTP-Client][handleHeaderResponse] RX: 'x-MD5: 64d43986a1e128adf07350b67441a6aa' [HTTP-Client][handleHeaderResponse] RX: 'Connection: close' [HTTP-Client][handleHeaderResponse] RX: 'Content-Type: application/octet-stream' [HTTP-Client][handleHeaderResponse] RX: '' [HTTP-Client][handleHeaderResponse] code: 200 [HTTP-Client][handleHeaderResponse] size: 208016 [httpUpdate] Header read fin. [httpUpdate] Server header: [httpUpdate] - code: 200 [httpUpdate] - len: 208016 [httpUpdate] - MD5: 64d43986a1e128adf07350b67441a6aa [httpUpdate] ESP8266 info: [httpUpdate] - free Space: 749568 [httpUpdate] - current Sketch Size: 296268 [httpUpdate] - current version: 1.1 [httpUpdate] runUpdate flash... [begin] roundedSize: 0x00033000 (208896) [begin] updateEndAddress: 0x00100000 (1048576) [begin] currentSketchSize: 0x00049000 (299008) [begin] _startAddress: 0x000CD000 (839680) [begin] _currentAddress: 0x000CD000 (839680) [begin] _size: 0x00032C90 (208016) MD5 Success: 64d43986a1e128adf07350b67441a6aa Staged: address:0x000CD000, size:0x00032C90 [httpUpdate] Update ok [HTTP-Client][end] tcp is closed wifi evt: 1 STA disconnect: 8

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1264, room 16 tail 0 chksum 0x42 csum 0x42 @cp:0 ld Hello, world. Hello, world. Hello, world. ...

[Links2004]

the best way it to use wire shark and checkt what the difference is in case of package size timings and so on. I have running some updates form a Server in the internet so in general its possible, your server must do something different then usual. did you server log show something?

[scottfuhrman]

So I fired up a private virtual server at DigitalOcean, ran the same php script there and it works fine. Still getting stream read timeout when trying to do the same thing from my web host (Dreamhost). How can I go about figuring out what Dreamhost is doing differently?

[scottfuhrman]

Well I have taken a wireshark trace of a good update to the DigitalOcean server, as well as an update that failed to the Dreamhost server with the stream read timeout error despite the file tranfer being successful.

The trace was taken by port mirroring my router's WAN port and filtering with the IP of the web server hosting the php script and .bin file.

To me both traces look pretty normal so I am not sure what is causing the failure on the esp8266 end. I am attaching the traces in case anyone can help.

failed_http_update.zip good_http_update.zip

[kaeferfreund]

I have been experiencing the same issue when trying to upload the exact same binary that was already running on the chip. All other binaries work fine from my "cheap" webspace...

[scottfuhrman]

Hmm. In my case the file being uploaded to the esp8266 is a different binary than what it is currently running, just a "hello world" for testing the process.

[jdkanani]

Facing same issue while using nginx reverse proxy.

[igrr]

@scottfuhrman @jdkanani Could you guys give me a link to the binary which fails to load (Dreamhost or nginx reverse proxy)? I'll test it on my side. Thanks.

[glynhudson]

Hi @igrr, Same timeout issue: ERROR[6]: Stream Read Timeout68

Here is my binary from a git release served via a PHP script:

http://lab.megni.co.uk/esp/firmware.php?tag=0

I'm following the continuous testing and deployment workflow detailed here to build and deploy update from git release: http://blog.squix.org/2016/06/esp8266-continuous-delivery-pipeline-push-to-production.html

The PHP script I'm running is in the ota folder in my git project repo: https://github.com/openenergymonitor/EmonESP/blob/ota/ota/firmware.php

Here is the update function: https://github.com/openenergymonitor/EmonESP/blob/ota/src/src.ino#L385

Server is apache running locally so timeout should not be an issue.

Could be a simple fix of increasing the timeout of the request?

[glynhudson]

Any progress on this? Could a bounty source be assigned?

Is the same issue reported here? https://github.com/esp8266/Arduino/issues/1177

[sticilface]

I'm getting this a lot at the moment and not exactly sure why..

[event_send, line 1248] EVENT: top = upgrade, msg = firmware
[httpUpdate] Header read fin.
[httpUpdate] Server header:
[httpUpdate]  - code: 200
[httpUpdate]  - len: 446128
[httpUpdate] ESP8266 info:
[httpUpdate]  - free Space: 602112
[httpUpdate]  - current Sketch Size: 444032
[httpUpdate] runUpdate flash...
sleep disable
[httpUpdate] Update.writeStream failed! (ERROR[6]: Stream Read Timeout)
[httpUpdate] Update failed
[_upgrade, line 1176] HTTP_UPDATE_FAILD Error (6): Update error: ERROR[6]: Stream Read Timeout[event_send, line 1248] EVENT: top = upgrade, msg = ERROR [Update error: ERROR[6]: Stream Read Timeout]
[event_send, line 1248] EVENT: top = upgrade, msg = end

[albertcaba]

Hi any update¿¿ I keep on getting this error. I have tried with local webservers in a raspberry pi , and using windows 10. Can it have a relation with using Php? Thanks

[tarjes]

The Stream Read Timeout started occurring again for me when upgrading from 2.4.0-rc2 to 2.4.0. However, OTA works when using lwIP v1.4 Prebuilt. Was lwIP v1.4 Prebuilt default in 2.4.0-rc2?

OTA upgrade attempts with lwIP v2 Prebuilt (MSS536): 1 success, 9 fail (stream read timeout)
OTA upgrade attempts with lwIP v1.4 Prebuilt: 10 success, 0 fail

thanks

[pat1]

I have the same problem with wemos d1 mini and wemos d1 minipro boards and esp8266 2.4.0. I use a django python app to provide firmware on the web: https://github.com/r-map/rmap/tree/master/python/firmware_updater that provide firmware for example at: http://rmap.cc/firmware/update/ESP8266_WEMOS_D1MINI/ The current version to provide for an upgrade should be something like: {"ver":"2018-02-04T00:00"}

adding some more debug in ESP8266httpUpdate.cpp as: if(int mysize=Update.writeStream(in) != size) { _lastError = Update.getError(); Update.printError(error); error.trim(); // remove line ending DEBUG_HTTP_UPDATE("[httpUpdate] Update.writeStream failed! (%s)\n", error.c_str()); DEBUG_HTTP_UPDATE("[httpUpdate] size: (%d) mysize=(%d)\n", size,mysize); return false; }

I get:

N: url for firmware update: /firmware/update/ESP8266_WEMOS_D1MINI/

N: version for firmware update: {"ver":"2018-02-04T00:00","user":"pat1","slug":"luftdaten"}

[httpUpdate] Header read fin. [httpUpdate] Server header: [httpUpdate] - code: 200 [httpUpdate] - len: 414304 [httpUpdate] - MD5: 15d14e0d73951d203860d4ff4abf578d [httpUpdate] ESP8266 info: [httpUpdate] - free Space: 630784 [httpUpdate] - current Sketch Size: 417120 [httpUpdate] - current version: {"ver":"2018-02-04T00:00","user":"pat1","slug":"luftdaten"} [httpUpdate] runUpdate flash... [httpUpdate] Update.writeStream failed! (ERROR[6]: Stream Read Timeout) [httpUpdate] size: (414304) mysize=(1) [httpUpdate] Update failed

E: [update] Update failed.

E: Update error: ERROR[6]: Stream Read Timeout

when I activate debug on update:

N: version for firmware update: {"ver":"2018-02-04T00:00","user":"pat1","slug":"stimaesp"}

[begin] roundedSize: 0x00066000 (417792) [begin] updateEndAddress: 0x00100000 (1048576) [begin] currentSketchSize: 0x00066000 (417792) [begin] _startAddress: 0x0009A000 (630784) [begin] _currentAddress: 0x0009A000 (630784) [begin] _size: 0x00065260 (414304) ERROR[6]: Stream Read Timeout

E: [update] Update failed.

E: Update error: ERROR[6]: Stream Read Timeout

For what I understand the problem is Update.writeStream(in) return 1

[horendus]

I'm also having the same problem since switching to 2.4.0 and lwIP v2 Prebuilt. OTA updates fail MOST of the time with Stream Read Timeout, however every 9 or 10 attempts it is successful.

After recompiling with wIP v1.4 Prebuilt OTA updates are working once again every time so lwIP v2 seems to has a serious bug effecting OTA.

[d-a-v]

Please retry with latest git master and report. OTA has been fixed since 2.4.0 release.

[pat1]

The last git work sometimes but do not solve for me. With wIP v1.4 Prebuilt OTA seem to work better. With more time I can report some statistical results.

[pat1]

There is a new release of LWIP: https://github.com/espressif/ESP8266_NONOS_SDK/releases

[horendus]

I can give it it a go, whats the easiest way to compile my ESP8266 sketch with the new version of LWIP?

[d-a-v]

It is a new release of our SDK. esp8266/Arduino (what we call the core here) uses the esp8266 on top of the espressif's esp8266-NonOS-SDK v2.1(+some commits), and v2.2 has just been just released. In it there are some commits about lwIPv1.4 and we are already using some of them. Our version of the core is 2.4.0, it will be updated to 2.4.1 soon, and it will likely be using ~sdk-v2.1~(!) sdk-v2.2.

[horendus]

Ok thanks D.A.V I will wait for the 2.4.1 core release then.

The IwIPv 1.4 although has stable OTA it cannot handle my with WebGUI running within my EPS8266 project so I will keep using IwIPv v2 and put up with having to run OTA updates a few times before it works.

[horendus]

$15 bounty placed on fixing this.

[d-a-v]

@horendus @pat1 Does it happen too with lwip-v2 "Higher Bandwidth" ?

[pat1]

I cannot get deterministic response ...

After this pull request https://github.com/esp8266/Arduino/pull/4365 seems to work better (I use WiFiManager before OTA https://github.com/tzapu/WiFiManager/issues/514#event-1475108491) but sometime I get :

E: [update] Update failed.

E: HTTP error: connection refused

There is no deterministic difference in behavior with lwip-v2 "Higher Bandwidth".

I come back to use 2.3.0

[garageeks]

I can confirm with IwIp v2 on SDK 2.4.0 fails with the stream error. I was puzzled by it when I found this open issue here. When downgrading to IwIP 1.4 Higher Bandwidth it worked at first attempt Seems IwIp 2.0 is still buggy

[devyte]

Please retest with release 2.4.1. There are known socket issues with 2.4.0.

[d-a-v]

@garageeks @pat1 @horendus

In order to narrow the issue, please confirm using:

• git version of the core and using lwip-v1.4 "higher bandwidth"
• git version of the core and using lwip-v2 "higher bandwidth"

otherwise (if git can't be available in your setup):

• core-2.4.1 and using lwip-v1.4 "higher bandwidth"
• core-2.4.1 and using lwip-v2 "higher bandwidth"

[pat1]

using git updated to 19/03/2018 and lwip-v2 "higher bandwidth" seems to work well !

[pat1]

sorry, there is a mistake in my previous message; should be: using git updated to 19/03/2018 and lwip-v2 "Lower memory" seems to work well !

[d-a-v]

Thanks for this feedback ! The "lower memory" test was the next question :) I would be nice to get @garageeks and @horendus's feedback too.

[ldab]

Getting ERROR[6]: Stream Read Timeout - on both 3 variants = v1.4 Higher Bandwidth, v2 Lower Memory and v2 Higher Bandwidth ESP-WROOM-02 SDK:2.2.1(cfd48f3) Core:2_4_1

[rohitjust24idpl]

Getting ERROR[6]: Stream Read Timeout on all variants, none of them seems to be working ? any leads on this ?

[jeffapp]

You can try this
if aways timeout stream add time values.

include

WiFiClient client;

client.setTimeout(5);

Will Done ~ ^^