search

raburton / esp8266

Various bits of code for ESP8266
http://richard.burtons.org/
183 stars 47 forks source link

ota fail on local server #17

Closed crosofg closed 9 years ago

crosofg commented 9 years ago

Hi I have started a wamp server and placed roms in the root directory. The ota sample proj is throwing following error. rBoot Sample Project

Currently running rom 0. type "help" and press for help... connect wifi connecting... network retry, status: 1 ip: 192.168.0.135 ota GET /rom1.bin HTTP/1.1 Host: 192.168.0.191 Connection: keep-alive Cache-Control: no-cache User-Agent: rBoot-Sample/1.0 Accept: /

Updating... Connection error. Firmware update failed!

Any ideas?

crosofg commented 9 years ago

the error code is -11. " Not Connected"

raburton commented 9 years ago

Sounds like it simply failed to connect to the web server. What you have in the log before that looks fine. Is the IP for the OTA server right, is the port correct, is there a firewall running? Have you checked you can connect to the webserver from another machine in the wifi? Ideally if you are sure everything is setup right run wireshark on the web server and see what is happening at the network level.

crosofg commented 9 years ago

This is the latest log. Although i have used the same roms which i flashed,It says both roms are bad. rBoot Sample Project

Currently running rom 0. type "help" and press for help... connect wifi connecting... ip: 192.168.0.107 ota GET /rom1.bin HTTP/1.1 Host: 192.168.0.191 Connection: keep-alive Cache-Control: no-cache User-Agent: rBoot-Sample/1.0 Accept: /

Rboot OTA Initialised Updating... Connect timeout. Firmware update failed! ota GET /rom1.bin HTTP/1.1 Host: 192.168.0.191 Connection: keep-alive Cache-Control: no-cache User-Agent: rBoot-Sample/1.0 Accept: /

Rboot OTA Initialised Updating... Upgrade Connected Upgrade Received HTTP/1.1 200 OK Content-Type: application/x-download Content-Disposition: attachment; filename=rom1.bin Content-Length: : 200320 Date: Sat, 22 Aug 2015 20:41:38 GMT Connection: keep-alive

j.Content Length is zero Inside write_flash Written Successfully addr 533744 ets Jan 8 2013,rst cause:4, boot mode:(3,7)

wdt reset load 0x40100000, len 1524, room 16 tail 4 chksum 0xfb load 0x3ffe8000, len 672, room 4 tail 12 chksum 0xf5 csum 0xf5

rBoot v1.2.1 - richardaburton@gmail.com Flash Size: 8 Mbit Flash Mode: QIO Flash Speed: 40 MHz

Rom 0 is bad. Rom 1 is bad. No good rom available. user code done

On Sat, Aug 22, 2015 at 11:14 PM, Richard Antony Burton < notifications@github.com> wrote:

Sounds like it simply failed to connect to the web server. What you have in the log before that looks fine. Is the IP for the OTA server right, is the port correct, is there a firewall running? Have you checked you can connect to the webserver from another machine in the wifi? Ideally if you are sure everything is setup right run wireshark on the web server and see what is happening at the network level.

— Reply to this email directly or view it on GitHub https://github.com/raburton/esp8266/issues/17#issuecomment-133732423.

raburton commented 9 years ago

Content-Length: : 200320 This is a bad header coming back from the server, it has an extra colon and space in it.

Content Length is zero And so it appears the length hasn't been parsed correctly.

It's probably going on to erase the first sector, then either write the first data packet or nothing at all, before thinking it is finished. Looks like the web server is causing the problem here.

crosofg commented 9 years ago

Can you send me a sample response header which worked with your rboot sample project ?

On Sun, Aug 23, 2015 at 1:56 PM, Richard Antony Burton < notifications@github.com> wrote:

Content-Length: : 200320 This is a bad header coming back from the server, it has an extra colon and space in it.

Content Length is zero And so it appears the length hasn't been parsed correctly.

It's probably going on to erase the first sector, then either write the first data packet or nothing at all, before thinking it is finished. Looks like the web server is causing the problem here.

— Reply to this email directly or view it on GitHub https://github.com/raburton/esp8266/issues/17#issuecomment-133802332.

Gaurav Gupta Department of Aerospace Engineering Indian Institute of Technology Kharagpur, Kharagpur, 721302 INDIA. Phone - +91 7501384704 gauravgupta.kgpr@gmail.com

raburton commented 9 years ago

Sure, but there is nothing special about the header I'm getting back, except for the fact that it's actually a valid header, unlike yours! Notice specifically the correctly specified Content-Length header, which is broken in your trace.

HTTP/1.1 200 OK Content-Type: application/octet-stream Last-Modified: Sun, 23 Aug 2015 15:52:38 GMT Accept-Ranges: bytes ETag: "81316bbcbbddd01:0" Server: Microsoft-IIS/7.5 X-Powered-By: ASP.NET Date: Sun, 23 Aug 2015 15:53:50 GMT Content-Length: 203392

crosofg commented 9 years ago

I am running a node server.I have rectified content-header issue. As per your response header their is nothing after "Content-Length: 203392". Your code takes anything after "Content-Length: 203392" as data. Where as in my header there are parameters "Date: Sat, 22 Aug 2015 20:41:38 GMT Connection: keep-alive" after content header. How do I determine the data location? Where should prtdata be pointing in writeFlash function?

raburton commented 9 years ago

Oh dear me, are you really trying to copy the header from my trace?

I have rectified content-header issue

You mean the Content-Length problem? How? Are you writing your own webserver, or are you serving the file as dynamic content in such a way that you are modifying the headers yourself? Neither of these seem like a good idea because you clearly don't understand the http specification.

Your code takes anything after "Content-Length: 203392" as data.

No it doesn't, it takes the data portion of the http response (after a properly formed header) as data.

Where as in my header there are parameters "Date: Sat, 22 Aug 2015 20:41:38 GMT Connection: keep-alive" after content header.

That's fine, the order of header fields doesn't matter.

How do I determine the data location? Where should prtdata be pointing in writeFlash function?

Where the data starts is defined in the http specification (after the \r\n\r\n at the end of the header) and is exactly where rBoot-ota code is looking for it.

There should be no need for any of this messing about. This is sample code and should just work as-is. I am aware of one bug that you could hit, which is that if the server sends the header as multiple chunks (there is one python based server that does this that I know of) it will not work because the code only looks for the header in the first packet. That does not appear to be the problem you are hitting.