Page 1 of 1

HTTP server unexpected socket reset

Posted: Wed Sep 18, 2019 4:38 pm
by SnifMyBack
Hi,
I just got another problem that can't find the reason why it does this weird result (thought I never played a lot with HTTP). So I'm trying to push a JSON array of more than 1000 bytes to the ESP32 (the ESP32 act as a server and an WiFi acces point). The ESP32 recognise the URI handler to choose and all the header in the HTTP request. Then, it begins to decode the result before the reset come (it's always at the elements 5). The error log I got look like that:

Code: Select all

[1B][0;33mW (228756) httpd_uri: httpd_uri: uri handler execution failed[1B][0m
D (228766) httpd: httpd_server: closing socket 63[1B][0m
D (228776) httpd_sess: httpd_sess_delete: fd = 63[1B][0m
D (228786) httpd: httpd_server: doing select maxfd+1 = 57[1B][0m
There is two ESP_LOG in this line if I'm correct ( "[1B][0;33m" and "(228756) httpd_uri: httpd_uri: uri handler execution failed[1B][0m")
At first I was sure that Google Chrome was resending a http post (or the tcp socket was resended) but by looking at Wireshark log, it's not. The server just close the socket for a reason that I don't understand.

If someone have an suggestion, I'll take it! in the meantime, I'll try to found the problem by looking at the drivers.

Re: HTTP server unexpected socket reset

Posted: Fri Sep 20, 2019 8:17 pm
by SnifMyBack
For now the bug seems to be gone without any clear reasons. The thing I can relate this bug to is task watchdog of FreeRTOS. I've played with the timming of my tasks and the bug didn't appear again. Thought, right now I have another problem: the httpd task seems to get stuck when the user is making action on the web page. Here's a quick look at the log:

Code: Select all

task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:[1B][0m
 task_wdt:  - httpd (CPU 0/1)[1B][0m
 task_wdt: Tasks currently running:
 task_wdt: CPU 0: IDLE0[1B][0m
 task_wdt: CPU 1: Request maker[1B][0m
[1B][0m
I've discovered that socket doesn't close correctly because when the session is finished my config.close_fn isn't always called. Anyone that have an idea of why the socket stay open?
Thanks