OTA not working anymore

gsieben commented 3 years ago

I have been programming with Platform IO for a while. I would like to take this chance to say a big thank you to the developers.

I now suddenly have a problem updating the ESP8266 via OTA. I get the error "[ERROR]: No response from device". But it worked just before. And on my other computer the update still works. So it's not the ESP. Unfortunately, I have no idea how to analyse this error. I have reinstalled Platform IO and Visual Sutdio code. No success. Any ideas?

Cheers Gabriel

boxofrox commented 3 years ago

So you have two computers. One can push an update over OTA (call this A), the other cannot (call this B). I would verify the network isn't the issue.

Can you ping the ESP8266 from computer A? If so, and B cannot ping, sounds like you have a firewall blocking B or a network misconfiguration. If A cannot ping, then find another way (maybe nmap/wireshark) to verify connectivity from A, and use that method to determine if B can "see" the ESP8266 on the same network. You might wonder, "why bother checking connectivity with A when we know OTA works?", well, we know A works with the OTA tool, we don't yet know if the ping tool will work for us, so we test ping against a known working system (A to ESP8266), so that we correctly interpret the result of pinging from B.

If B pings, then something is out of sorts, but I wouldn't know what. I'd use wireshark to capture an OTA session on computer A, then repeat with computer B, and compare to determine what's different and inconsistent.

If B doesn't ping, I'd crawl over the network config of B to determine if firewall is blocking OTA comms or B attached to wrong Wifi AP, or is on wrong subnet, etc.

Edit: Actually, regardless of whether B pings or not, if you're on Windows with Firewall enabled, I'd turn off Firewall while debugging, and double check OTA from B. The firewall can permit ICMP packets (ping) while rejecting TCP packets (OTA).

gsieben commented 3 years ago

Thank you and sorry for the late reply. No, it's not a firewall and it's not an antivirus program. But thanks for the tips. On another device with display I have now seen that the handshake takes place. But then it stops at 0%. I will have a closer look at that.

valeros commented 3 years ago

Hi @gsieben ! I just tried a simple example and everything went well. Do OTA updates work with Arduino IDE?

TD-er commented 2 years ago

Just browsed through the open issues here and maybe I can give some more ideas to test, as I've seen similar behavior before.

One device I have which does show similar behavior as you described was not possible to flash OTA when both the laptop and the ESP were connected to the same WiFi access point. The only solution for me at that time was to flash it using a wired computer. Not sure what may have caused it, as there are so many possibilities here, like:

ESP using 802.11g, laptop using 802.11n. AP may cause too much of a delay here for the ESP to handle
ESP does react not fast enough, while it also needs to write the stream to the flash
ESP is maybe also receiving data from other nodes occupying the TCP stack too much, causing timeouts
ESP may receive lots of interrupts on some pin (e.g. a very 'chatty' device connected to a software serial pin)

etc. In the end these suggestions all have the same common cause, where the WiFi may not respond in due time. (either side)

ketan commented 2 years ago

I'm seeing a similar issue, OTA seems to not work with platformio, but seems to work with arduino IDE.

Here's the output I'm seeing from esptool bundled with platformio:

 "/Users/ketanpadegaonkar/.platformio/penv/bin/python" "/Users/ketanpadegaonkar/.platformio/packages/framework-arduinoespressif32/tools/espota.py" --debug --progress -i 192.168.0.53 -f .pio/build/lolin32_mpu9250_ms5611/firmware.bin --timeout 6
12:57:55 [DEBUG]: Options: {'esp_ip': '192.168.0.53', 'host_ip': '0.0.0.0', 'esp_port': 3232, 'host_port': 51526, 'auth': '', 'image': '.pio/build/lolin32_mpu9250_ms5611/firmware.bin', 'spiffs': False, 'debug': True, 'progress': True, 'timeout': 6}
12:57:55 [INFO]: Starting on 0.0.0.0:51526
12:57:55 [INFO]: Upload size: 1039376
Sending invitation to 192.168.0.53 .
12:58:01 [INFO]: Waiting for device...
12:58:11 [ERROR]: No response from device

However running the same args with esptool bundled with Arduino seems to work just fine:

python /Users/ketanpadegaonkar/Library/Arduino15/packages/esp32/hardware/esp32/1.0.6/tools/espota.py --debug --progress -i 192.168.0.53 -f .pio/build/lolin32_mpu9250_ms5611/firmware.bin
13:01:20 [DEBUG]: Options: {'esp_ip': '192.168.0.53', 'host_ip': '0.0.0.0', 'esp_port': 3232, 'host_port': 33104, 'auth': '', 'image': '.pio/build/lolin32_mpu9250_ms5611/firmware.bin', 'spiffs': False, 'debug': True, 'progress': True, 'timeout': 10}
13:01:20 [INFO]: Starting on 0.0.0.0:33104
13:01:20 [INFO]: Upload size: 1039376
Sending invitation to 192.168.0.53
13:01:21 [INFO]: Waiting for device...
Uploading: [============================================================] 100% Done...

13:01:54 [INFO]: Waiting for result...
13:01:55 [INFO]: Result: OK
13:01:55 [INFO]: Success

Surprisingly, running platformio's esptool using my system python makes it work just fine:

python "/Users/ketanpadegaonkar/.platformio/packages/framework-arduinoespressif32/tools/espota.py" --debug --progress -i 192.168.0.53 -f .pio/build/lolin32_mpu9250_ms5611/firmware.bin --timeout 6
13:02:52 [DEBUG]: Options: {'esp_ip': '192.168.0.53', 'host_ip': '0.0.0.0', 'esp_port': 3232, 'host_port': 10710, 'auth': '', 'image': '.pio/build/lolin32_mpu9250_ms5611/firmware.bin', 'spiffs': False, 'debug': True, 'progress': True, 'timeout': 6}
13:02:52 [INFO]: Starting on 0.0.0.0:10710
13:02:52 [INFO]: Upload size: 1039376
Sending invitation to 192.168.0.53
13:02:52 [INFO]: Waiting for device...
Uploading: [============================================================] 100% Done...

13:03:20 [INFO]: Waiting for result...
13:03:21 [INFO]: Result: OK
13:03:21 [INFO]: Success

celsworth commented 1 year ago

I've just run into this today as well. Running on an M1 Mac with PIO 6.1.4. I can reproduce ketan's experience exactly. The only useful thing I have to add is I tcpdump'ed and while running pio run -t upload I saw absolutely zero traffic going out of the interface to the ESP. Not a sausage. So it seems the initial UDP packet is getting lost somewhere. When I run the manual command as per the comment above, something like:

python3 ~/.platformio/packages/framework-arduinoespressif8266/tools/espota.py --debug --progress -i 192.168.0.75 -f .pio/build/nodemcu/firmware.bin

Then it works and I get this on tcpdump:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en4, link-type EN10MB (Ethernet), capture size 262144 bytes
15:48:01.185892 IP 192.168.0.20.58493 > 192.168.0.75.8266: UDP, length 48
15:48:01.190438 ARP, Request who-has 192.168.0.20 tell 192.168.0.75, length 46
15:48:01.190481 ARP, Reply 192.168.0.20 is-at 64:4b:f0:10:d6:f9, length 28
15:48:01.192868 IP 192.168.0.75.8266 > 192.168.0.20.58493: UDP, length 2
15:48:01.292162 IP 192.168.0.75.51910 > 192.168.0.20.50825: Flags [S], seq 144605, win 2144, options [mss 536,nop,nop,sackOK], length 0
15:48:01.292410 IP 192.168.0.20.50825 > 192.168.0.75.51910: Flags [S.], seq 1539306075, ack 144606, win 65535, options [mss 1460,sackOK,eol], length 0
15:48:01.294602 IP 192.168.0.75.51910 > 192.168.0.20.50825: Flags [.], ack 1, win 2144, length 0
<snip, rest of transfer continues>

I will see if I can work out where that initial packet is going, perhaps being routed out the wrong interface but I've no idea why...

TD-er commented 1 year ago

I will see if I can work out where that initial packet is going, perhaps being routed out the wrong interface but I've no idea why...

ESP might have missed an ARP request. If you send out a few pings before updating, is the success rate higher then?

MarikTik commented 11 months ago

Same problem here, I am working with Ubuntu though I am not sure that it has connection. while pinging the esp network IP works just fine, telnet to 8266 port is being refused. Also when using Serial debugging it seems as the progress is initialized but stops at 0%.

TD-er commented 11 months ago

Do you call the ArduinoOTA.handle() function from the loop()?

MarikTik commented 11 months ago

Yes, I do

Link to my repo: MarikTik/Home-Network (github.com)

Control-Panel/src/components/ota.cpp

For default_envs in platformio.ini I choose release_ota (uncommented)

platformio / platform-espressif8266

OTA not working anymore #235