AT+CIPSEND bad payload on TCP packet

[MisterXYZ83]

Answers checklist.

• I have read the documentation ESP-AT Programming Guide and the issue is not addressed there.
• I have used the latest released firmware or have updated my ESP-AT branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I'm using an ESP32-C3 module for a home project; i'm experiencing sometimes a confusing behavior.

My firmware starts configuring the module at 115200 baud and then switch to 460800 baud; then i configure a TCP server in multiple connection context (AT+CIPMUX=1). Everything working fine, the fw application sends data to connected remote client without problems.
Sometimes happens that when fw application needs to send data (using AT+CIPSEND,,....) i capture with wireshark (during debug analysis) packets with a wrong byte on the top of the buffer.

for example:

1. fw app needs to send 0x0102030405 (5 bytes)
2. captured with an uart sniffer (a couple of ftdi module on TX and RX line between esp32 and microcontroller) the at command AT+CIPSEND,0,5\r\n
3. esp32 ack request with OK\r\n and give data wrapper ">"
4. microcontroller send data (0x0102030405) and data is correctly captured by sniffer
5. esp32 confirm reception (Recv 5 bytes\r\n");
6. SEND OK
7. on wireshark i got a bad packet with payload of 0x0A01020304 => last byte trunked and first filled with 0x0A

I'm not sure why it happens and don't know how to solve....i tried to configure baudrate to 115200 and seems to solve but i'd need to have a faster channel.
My analysis on many faulty packets reports that always the first bad byte is 0x0A, like if the module buffered the last 0x0A byte of "AT+CIPSEND,xx,nnn\r\n" transaction...

Thanks

[ustccw]

@MisterXYZ83 Hi, there is a debugging examples for this case - could you please give it a try?
https://docs.espressif.com/projects/esp-at/en/latest/esp32c3/Compile_and_Develop/How_to_enable_more_AT_debug_logs.html#debugging-examples

In general, you can enable AT Network Function Debugging and AT Interface Function Debugging, and then capture the packets. i believe this issue can be resolved shortly.