Good question, in the non-password case there is one round trip less in the UDP connection. PC sends UDP packet to ESP with update info, ESP returns OK via UDP, then they switch to a TCP connection and the update starts. In the other case it does Update Info → Challenge info → Challenge response → OK → TCP update.
In any case, you do see that UDP “OK” packet in Wireshark from the perspective of the PC for the non-password case but not in the password case, right?
Right! I edited my last post to show it.
Can you replace this
code with like
for(int i=0; i < 3; i++) {
_udp_ota->append("OK", 2);
_udp_ota->send(ota_ip, _ota_udp_port);
delay(100);
Serial.println("Sending UDP 'OK' packet nr " + String(i+1) + " to " + ota_ip.toString() + " port " + String(ota_udp_port));
while(_udp_ota->next()) _udp_ota->flush();
Serial.println("Flush done");
}
delay(100);
and check again if there is no UDP “OK” packet in the password case?
That did the trick somehow - but whyever?
sld▒▒|▒c▒o
▒l▒p▒r▒▒▒{▒B▒B▒▒nn▒loo▒▒▒bp▒▒cl`{$p▒N▒
▒
l▒▒
c
o▒|▒l▒▒
▒p
▒▒NN▒l▒▒l`▒o
d ns▒▒▒ob$`{▒▒{bl`▒c
▒▒$s▒`▒n▒
SDK:2.2.2-dev(38a443e)/Core:2.7.3-3-g2843a5ac=20703003/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be
.
__OK__
pm open,type:2 0
19:51:53
19:52:03
19:52:13
19:52:23
to OTA_RUNUPDATE
In _runUpdate()
sleep disable
[begin] roundedSize: 0x00050000 (327680)
[begin] updateEndAddress: 0x00300000 (3145728)
[begin] currentSketchSize: 0x00050000 (327680)
[begin] _startAddress: 0x002B0000 (2818048)
[begin] _currentAddress: 0x002B0000 (2818048)
[begin] _size: 0x0004FE30 (327216)
Update.begin() OK
Sending UDP 'OK' packet nr 1
Flush done
Sending UDP 'OK' packet nr 2
Flush done
Sending UDP 'OK' packet nr 3
Flush done
Connect about to begin
Connect OK
Header: 0xE9 1 2 40
while loop ended written=176 total=327216
MD5 Success: 3eb601e96b73c592bee2a53aaf759eea
Staged: address:0x002B0000, size:0x0004FE30
Update.end() OK
Update Success
Rebooting...
state: 5 -> 0 (0)
rm 0
pm close 7
del if0
usl
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 3584, room 16
tail 0
chksum 0xb0
csum 0xb0
v2843a5ac
@cp:0
ld
Yaay, a success at last 
So it really just drops the first packet? But why? Is this router dependent? Does the ESP’s UDP stack have a bug that causes it to just not send it?
Can you also check that it’s purely due to sending the packet twice and not via the delays introduced by the serial code by changing it to for(int i=0; i < 2; i++) { and commending out the Serial prints in the loop?
This
is from the change log for the previous FritzOS version I had on my box.
The failure of OTA about started at the time the box was updated to FritzOS 7.21… 
Interesting. Is there any change if you remove this?
Could be some lwIP stack weirdness.
Sadly the lwIP stack is sourced from a static library and cannot be recompiled from source to activate its print statements.
Well that is also definitely a very good possible cause.
Still the Arduino-ESP8266 implementation could be better here and at least try to reliably send that “OK” packet. They are working with UDP here, so packet loss must be expected.
No, does not change a bit. Still only one of the two OK packets can be found.
Then my best guess is that they re-introduced the bug in the later firmware versions again.
This is however as I think fix-worthy in the ESP8266 core. A little bit of reliability on that OK packet would be good (or other packets in general). Can you open an issue in Issues · esp8266/Arduino · GitHub for that? You have a pretty good case here with that router bug for the issue to be taken seriously.
I followed a thread on Fritz.box UDP packet losses in the meantime and applied a workaround they were proposing there (disable hardware packet speed-up). Voilà - the two OK packets are there.
Looks like they reintroduced some bug in FritzOS at AVM.
I made not the best of experiences there in regards of being noticed at all… I will try nevertheless.
Thank you for all the help! 
Stuck again, after a year. There was another Fritzbox update last night, but this time the old remedy did not work again. Even with deactivated packet speed-up the issue is remaining.
Without taking the devices apart, I can not update the code for the improved ArduinoOTA.cpp, as suggested above. So I am at a dead end…
I am still blocked with this. I found no way yet to get OTA working again and now urgently need to update my devices. These are spread all over the place in dusty corners and behind furniture, so I am craving for some fix to not have to crawl around.
I think I got it - the esptool error message is misleading, so it seems. The last UDP packet from the device as is caught by Wireshark is
0000 30 85 a9 40 0b 23 24 a1 60 1c 83 d8 08 00 45 00 0..@.#$.`.....E.
0010 00 3d 00 30 00 00 ff 11 d5 cf c0 a8 b2 34 c0 a8 .=.0.........4..
0020 b2 2a 20 4a ee a1 00 29 d9 3a 45 52 52 3a 20 45 .* J...).:ERR: E
0030 52 52 4f 52 5b 34 5d 3a 20 4e 6f 74 20 45 6e 6f RROR[4]: Not Eno
0040 75 67 68 20 53 70 61 63 65 0d 0a ugh Space..
So it looks like the 1M memory is busted with the upload.