ESP8266 Community Forum

Does the output "FindConnData: Huh? Couldn't find connection for 0x3ffe9bec" indicate that a socket or context was closed too early? This only happens if I connect to the ESP through my router. There is no problem if I connect to it as an AP.

Here's the output of my ESP after startup and a single request from a browser for http://192.168.1.108/wifi. It then reconnects to my router after this. In many cases, it takes 3 reconnects to recover and sometimes will also reset the ESP. I have a clean 3A 3.3V supply, so I know power is not the culprit.



l r n p < lp nn ; n b $p n l b n n l p nn l` # n nr ? l p n r pp 8 nn # n $ l` 8`rn|
n b l`9 # n $ nn l`nn r l 8p l 8 nn l` # nnr l` 8 l` r CC Q*TN 6 in STATIONAP mode, restarting in STATIONAP
mode...
ESP8266 in AP mode configured.
ESP8266 in STA mode configured.
Wi-Fi mode: STATIONAP
AP config: SSID: ESP8266, PASSWORD: password
STA config: SSID: roberts, PASSWORD: password
Httpd init, conn=0x3ffe9bec

Ready
mode : sta(18:fe:34:99:38:c7) + softAP(1a:fe:34:99:38:c7)
add if0
dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
add if1
bcn 100
scandone
add 0
aid 4
cnt

connected with roberts, channel 7
dhcp client start...
ip:192.168.1.108,mask:255.255.255.0,gw:192.168.1.254
Con req, conn=0x3fff5cb0, pool slot 0
Con req, conn=0x3fff5860, pool slot 1
URL = /wifi
Is url index 6
Conn 0x3fff5cb0 is done. Closing.
URL = /wifi/wifi.tpl
Is url index 9
Heatshrink compressed file; decode parms = b4
rm match
FindConnData: Huh? Couldn't find connection for 0x3ffe9bec
ReconCb
reconnect
scandone
add 0
aid 4
cnt

connected with roberts, channel 7
dhcp client start...
ip:192.168.1.108,mask:255.255.255.0,gw:192.168.1.254

It's basically a bug /featurein the ESP SDK: sometimes, when a socket closes, the callback will return the listening socket instead of the one actually closed. It shouldn't harm the workings of esp-httpd: it has a different way of figuring out what connection is done. I think I removed the message in later versions.

I don't know what you mean by "it shouldn't harm the workings of esp-httpd". It hardly ever works when accessing the ESP as a station. It reconnects, runs out of heap or resets. The browser just sits there waiting for the page that often never arrives. It is very stable when accessed as an AP though. I am really surprised that I seem to be the only one reporting this problem.

BTW, I am using "Espressif DevKit for Windows + Eclipse IDE" by CHERTS to build esp-httpd. Maybe it compiles better in Linux?

Same thing happened to me too, but I do not think It is caused by closing connection early. I managed to get rid of it by flashing blank.bin and default init data present in IoT SDK.

Also if you keep GPIO0 low for 5 seconds esphttpd switches to AP+STA mode and reboots ESP - in my expirience this usually is the cause of broken init data and described behaviour. You might want to comment it out in io.c