Large File Transfer Over TCP Fails when Client Is on 5GHz Wi-Fi (Buffer Overrun/Throughput Issue) (EHM-92) #89
Description
Checklist
- Checked the issue tracker for similar issues to ensure this is not a duplicate
- Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
- Tested with the latest version to ensure the issue hasn't been fixed
How often does this bug occurs?
always
Expected behavior
Transfer files of 1MB size over TCP raw from an android phone. It works perfectly when both devices are in 2.4GHz network. But when client is in 5Ghz network the error occurs.
Actual behavior (suspected bug)
I'm using the ESP-Hosted MCU solution (ESP32-C6 as the slave, with an external host). The ESP-Hosted slave is connected to a 2.4GHz Wi-Fi AP. When a TCP client (e.g., a PC or smartphone) is connected to the same network, but on 5GHz Wi-Fi, attempting to transfer large files (1MB+) over TCP results in unreliable transfers—connections stall, packets are lost, or transfers are reset.
If the client is on 2.4GHz, everything works correctly.
Configuration:
ESP-Hosted Slave: ESP32-C6, connected to 2.4GHz AP as client
TCP Client: [PC/phone details], connected to 5GHz AP (same LAN/subnet)
Transport: [SDIO/SPI/UART] (please specify)
Slave firmware version: [commit/hash/version]
Host: [MCU type, OS, SDK version]
esp-hosted-mcu repo: [link if needed]
Symptoms:
Large TCP file transfers (>1MB) between client and slave work when the client is on 2.4GHz, but fail or stall if the client is on 5GHz.
Serial logs from the slave show queue overflows, buffer allocation failures, or lost packets during high-throughput on 5GHz.
Small transfers and pings are reliable regardless of client band.
Analysis/What I Tried:
Increased TO_HOST_QUEUE_SIZE and buffer sizes—no permanent improvement.
Tried various TCP window/chunk sizes.
Adjusted application-level flow control.
No issues observed if both slave and client use 2.4GHz.
Questions:
Are there known interoperability issues with ESP-Hosted when the TCP peer is on a different Wi-Fi band (5GHz client to 2.4GHz slave)?
Is the firmware or network stack less tolerant of high-throughput or fast-paced 5GHz-to-2.4GHz transfers?
Are there specific queue/buffer parameters or flow control tweaks recommended for this scenario?
How can we debug or tune the system for stable, reliable large file transfers across Wi-Fi bands?
Is there a roadmap or planned fix for this type of mixed-band performance issue?
Steps to Reproduce:
Start ESP-Hosted slave (ESP32-C6) on 2.4GHz Wi-Fi AP.
Connect a TCP client on the same LAN, but via 5GHz Wi-Fi.
Transfer a large file (e.g., 1MB) over TCP.
Observe stalls, resets, or packet loss.
Repeat with client on 2.4GHz: works fine.
Error logs or terminal output
I (393944) tcp_file_recv: Client connected
I (393944) tcp_file_recv: Ready to receive up to 2097152 bytes
W (408733) rpc_core: Timeout waiting for Resp for Req[0x103]
E (408733) rpc_core: Response not received for [0x103]Steps to reproduce the behavior
Settings on the Host CPU ESP32P4:
LWIP_TCPIP_RECVMBOX_SIZE:12,
LWIP_UDP_RECVMBOX_SIZE:6,
LWIP_TCP_RECVMBOX_SIZE:6,
CONFIG_LWIP_TCP_SND_BUF_DEFAULT=32768
CONFIG_LWIP_TCP_WND_DEFAULT=32768
Sending a 1MB File over TCP by an android app
Project release version
2.1.10
System architecture
other (details in Additional context)
Operating system
Windows
Operating system version
11
Shell
other (details in Additional context)
Additional context
I use ESP-IDF via VS Code