esp-idf: Intermittent http server error: httpd_txrx: httpd_sock_err: error in recv : 104 (IDFGH-5593)
Environment
- Development Kit: ESP32-PICO-Kit
- Kit version (for WroverKit/PicoKit/DevKitC): v4.1
- Module or chip used: ESP32-PICO-D4
- IDF version (run
git describe --tagsto find it): 4.3 - Build System: idf.py
- Compiler version (run
xtensa-esp32-elf-gcc --versionto find it): 8.4.0 - Operating System: WIndows 10
- (Windows only) environment type: PowerShell
- Using an IDE?: Yes (Eclipse)
- Power Supply: USB
Problem Description
I am running an application on my ESP32 Pico kit which runs an http REST server which also serves files. I have a number of request handlers for REST paths, and I have one handler for a built-in web page which is modeled after the example code provided by Espressif for a REST server. It serves web pages from a spiffs partition.
I run the server continually and have the monitor on. Approximately once per day I will get a couple of messages on the monitor as follows:
W (923632) httpd_txrx: httpd_sock_err: error in recv : 104
W (923642) httpd_txrx: httpd_sock_err: error in recv : 104
These will occur even though my server is IDLE: I have no requests for web pages or REST commands being sent. The application otherwise appears to be working normally, and I have not noticed an error in behavior other than to see these warnings appear. If fact, if I execute a wide variety of REST API calls and make requests to the web server, I do not get these messages. They seem to appear independent of my use of the server.
I’ve done quite a bit of research on the 104 (connection reset by peer) error but have not been able to come to a conclusion on what the cause could be, especially since they occur when I am not making any requests to the server.
Expected Behavior
During operation of http server application, I should not see 104 (connection reset by peer) errors
Actual Behavior
During operation of http server application, I occasionally see 104 (connection reset by peer) errors, even if I am not making any requests to the server
Steps to reproduce
- Start application with console monitor connected and on
- Start http server and verify correct initialization and operation of the REST API and http server without errors or warnings
- Stop sending commands/requests to the server and let it run idle for up to 1 day
- Observe 104 error appear on the monitor
Code to reproduce this issue
// the code should be wrapped in the ```cpp tag so that it will be displayed better.
#include "esp_log.h"
void app_main()
{
}
// If your code is longer than 30 lines, GIST is preferred.
Debug Logs
Here’s the monitor output beginning with boot-up
entry 0x40080678
I (27) boot: ESP-IDF v4.3-dirty 2nd stage bootloader
I (27) boot: compile time 17:53:18
I (27) boot: chip revision: 1
I (31) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (38) boot.esp32: SPI Speed : 40MHz
I (42) boot.esp32: SPI Mode : DIO
I (47) boot.esp32: SPI Flash Size : 4MB
I (51) boot: Enabling RNG early entropy source...
I (57) boot: Partition Table:
I (60) boot: ## Label Usage Type ST Offset Length
I (68) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (75) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (83) boot: 2 factory factory app 00 00 00010000 00100000
I (90) boot: 3 www Unknown data 01 82 00110000 00032000
I (97) boot: End of partition table
I (102) boot_comm: chip revision: 1, min. application chip revision: 0
I (109) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=1fb84h (129924) map
I (166) esp_image: segment 1: paddr=0002fbac vaddr=3ffb0000 size=0046ch ( 1132) load
I (167) esp_image: segment 2: paddr=00030020 vaddr=400d0020 size=a1c30h (662576) map
I (422) esp_image: segment 3: paddr=000d1c58 vaddr=3ffb046c size=0409ch ( 16540) load
I (429) esp_image: segment 4: paddr=000d5cfc vaddr=40080000 size=16f4ch ( 94028) load
I (469) esp_image: segment 5: paddr=000ecc50 vaddr=50000000 size=00010h ( 16) load
I (482) boot: Loaded app from partition at offset 0x10000
I (482) boot: Disabling RNG early entropy source...
I (494) cpu_start: Pro cpu up.
I (494) cpu_start: Starting app cpu, entry point is 0x40081498
0x40081498: call_start_cpu1 at C:/Users/mdbra/Documents/esp-idf/components/esp_system/port/cpu_start.c:141
I (0) cpu_start: App cpu up.
I (508) cpu_start: Pro cpu start user code
I (508) cpu_start: cpu freq: 160000000
I (508) cpu_start: Application information:
I (513) cpu_start: Project name: BD-PTB
I (517) cpu_start: Compile time: Jul 23 2021 06:00:27
I (524) cpu_start: ELF file SHA256: ca02407320255093...
I (530) cpu_start: ESP-IDF: v4.3-dirty
I (535) heap_init: Initializing. RAM available for dynamic allocation:
I (542) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (548) heap_init: At 3FFB8ED0 len 00027130 (156 KiB): DRAM
I (554) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (561) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (567) heap_init: At 40096F4C len 000090B4 (36 KiB): IRAM
I (574) spi_flash: detected chip: gd
I (578) spi_flash: flash io: dio
I (583) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (592) BD-PTB: Setting up I/O
I (602) BD-PTB: Setting up LEDs
I (1102) BD-PTB: Setting up buttons
I (1102) gpio: GPIO[37]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:3
I (1102) gpio: GPIO[38]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:3
I (1112) BD-PTB: Configuration
I (1142) BD-PTB: Running SW version 1.2
I (1142) BD-PTB: Configuring points
I (1152) BD-PTB: WifiLink: starting WiFi
I (1172) wifi:wifi driver task: 3ffc62fc, prio:23, stack:6656, core=0
I (1172) system_api: Base MAC address is not set
I (1172) system_api: read default base MAC address from EFUSE
I (1192) wifi:wifi firmware version: c7d0450
I (1192) wifi:wifi certification version: v7.0
I (1192) wifi:config NVS flash: enabled
I (1192) wifi:config nano formating: disabled
I (1192) wifi:Init data frame dynamic rx buffer num: 32
I (1202) wifi:Init management frame dynamic rx buffer num: 32
I (1202) wifi:Init management short buffer num: 32
I (1212) wifi:Init dynamic tx buffer num: 32
I (1212) wifi:Init static rx buffer size: 1600
I (1212) wifi:Init static rx buffer num: 10
I (1222) wifi:Init dynamic rx buffer num: 32
I (1222) wifi_init: rx ba win: 6
I (1232) wifi_init: tcpip mbox: 32
I (1232) wifi_init: udp mbox: 6
I (1232) wifi_init: tcp mbox: 6
I (1242) wifi_init: tcp tx win: 5744
I (1242) wifi_init: tcp rx win: 5744
I (1252) wifi_init: tcp mss: 1440
I (1252) wifi_init: WiFi IRAM OP enabled
I (1252) wifi_init: WiFi RX IRAM OP enabled
I (1262) BD-PTB: WifiLink: Checking for existing Wifi connection
I (1272) phy_init: phy_version 4670,719f9f6,Feb 18 2021,17:07:07
I (1362) wifi:mode : sta (d8:a0:1d:5d:cb:64)
I (1372) wifi:enable tsf
I (1382) wifi:new:<7,0>, old:<1,0>, ap:<255,255>, sta:<7,0>, prof:1
I (1382) wifi:state: init -> auth (b0)
I (1382) wifi:state: auth -> assoc (0)
I (1392) wifi:state: assoc -> run (10)
I (1412) wifi:connected with Antioch, aid = 3, channel 7, BW20, bssid = 20:c9:d0:20:04:e7
I (1412) wifi:security: WPA2-PSK, phy: bgn, rssi: -49
I (1412) wifi:pm start, type: 1
I (1412) wifi:AP's beacon interval = 102400 us, DTIM period = 3
I (1422) BD-PTB: wifiEvent: wifi connected
I (3152) esp_netif_handlers: sta ip: 192.168.1.32, mask: 255.255.255.0, gw: 192.168.1.1
I (3152) BD-PTB: wifiEvent: wifi obtained IP
I (3152) BD-PTB: Wifi connected with prior configuration
I (3162) BD-PTB: SSID = Antioch
I (3162) BD-PTB: MAC address = D8:A0:1D:5D:CB:64
I (3172) BD-PTB: IP address = 192.168.1.32
I (3172) BD-PTB: Gateway = 192.168.1.1
I (3182) BD-PTB: Netmask = 255.255.255.0
I (3182) BD-PTB: Setting up mDNS
I (3192) BD-PTB: mDNS host name = BD-PTB-5DCB64
I (3202) BD-PTB: Starting web server
I (3202) BD-PTB: Starting HTTPD server
I (3222) BD-PTB: Partition /www size: total: 180971, used: 58232
I (3472) BD-PTB: Initialization complete
W (923632) httpd_txrx: httpd_sock_err: error in recv : 104
W (923642) httpd_txrx: httpd_sock_err: error in recv : 104
Other items if possible
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 19 (1 by maintainers)
Hi @CharlesScoville
Thanks for your investigations and explanations. I agree it is not critical, but it can confuse users (we had that quite often). And since we as device developers can not fix it, I think it would be great if this warning could get disabled or catched or changed to debug log.
I know we closed this, but not because it’s not there. 😃 I’m still getting this issue and it sometimes causes a disruption in the wifi communication: for a few seconds, a client is unable to connect to the ESP32.