ESP32-S2 TCP Previous Segment Not Captured

asked 2025-07-16 20:47:44 +0000

Hello,

I'm having an issue with my ESP32-S2-SOLO-2U-N4 device where occasionally I am getting a "TCP Previous Segment Not Captured" message in response to a data packet coming in. Please see file here: https://www.dropbox.com/scl/fi/9xl8h9...

A little background info - I have a LabVIEW application that sends packets of data (7 bytes) every ~50ms to my ESP32-S2. On the other end of the ESP32-S2 I have an MCU. So the ESP32-S2 is really just a liaison between the two (I understand that the ESP device can act as an MCU as well... These are design constraints I currently have). Anyways, the ESP32-S2 forwards the TCP data to Serial to the MCU, the MCU processes the data and responds via Serial with a 14-byte packet. The ESP32-S2 takes that packet and sends it over TCP back to LabVIEW to read.

Note: This is a pretty large file. The main IP addresses here are 192.168.1.201 (my PC w/ LabVIEW) and 192.168.1.170 (ESP32-S2) but some lines of interest are 2992-2995, 2329-2332, and 1757-1760 (among others). You'll notice that the two communicate well the vast majority of the time, but occasionally this error happens and it takes ~1 second to get back to normal comms which I can not have.

I've tried a slew of different programming methods, firmware, and such with no luck. The only thing really remaining for me to try would be using the ESP-IDF but I am having a very difficult time even installing the software so I've kind of turned away from that (at the moment, anyway). Thanks in advance.

edit retag flag offensive close merge delete

Comments

What is the connection between PC and ESP? Is there a device to make a capture on?

Chuckc ( 2025-07-17 12:29:02 +0000 )edit

They communicate over TCP but both are on the same router, so WiFi is the connection between the two. I've just been running Wireshark on my PC w/ LabVIEW and capturing.

My MCU program sends out a "beep" when data is not received after some period of time (generally a little over a second) so I can audibly tell when this communication error occurs.

I've had a little success actually by coding a "manual retransmission." Essentially, if the ESP32-S2 doesn't receive TCP within ~250ms, I automatically send the previous packet it transmitted (basically a spurious retransmission of sorts). While I don't think this is an elegant solution, it does seem to jostle around the comms and prevent >1sec of lull.

jbrinker2 ( 2025-07-17 13:05:01 +0000 )edit

Capturing in the middle is one step closer to verifying that the packet that is retransmitted was sent the first time to the ESP.

Chuckc ( 2025-07-17 18:25:50 +0000 )edit

add a comment

answered 2025-07-17 19:40:14 +0000

SYN-bit

18600 ●9 ●360 ●255 https://SYN-b.it

Looks like normal packetloss that can occur on WiFi networks as it is a shared medium. The retransmission timeout (RTO) on the LabView PC seems to be 300ms (very normal for old Windows versions) The RTO on the ESP seems to be 1000ms. Unless you're able to tune the TCP stacks on both to use a much lower RTO, you ware out of luck with TCP as your application requires quicker retransmissions of the data. Quickly sending the data again over TCP won't help, as the data will be stuck in the TCP buffers and only will be handed over to the application when the original missing data segment is received (ie with the same sequence numbers).

I would change your setup to UDP and add some form of sequence number to the messages. Add a form of acknowledgement system and retransmit messages if not acknowledged within a certain timeout. This will remove the head-of-line blocking that TCP introduces.

edit flag offensive delete link

Comments

Also, I think you should remove the pcap file due to some sensitive information in it and replace it with only the traffic to/from the ESP (you can use File -> export specified packets... to save only the packets that match the display filter to disk).

SYN-bit ( 2025-07-17 19:48:47 +0000 )edit

I appreciate the input here. Your comment makes sense, that is kind of where I am at with this as well. Unfortunately TCP is another current design constraint I have... Its interesting though, the current application uses an RN171 WiFi module (obsolete) but it seems to be much more robust in terms of sending spurious retransmissions, likely based on the RTO in its TCP stack.

I've had success with tuning some of the ESP's TCP stack as well as adding my own sort of spurious retransmission. While it certainly doesn't function to send a meaningful packet of data, it does seem to re-establish normal TCP communication in far less than 1 second which I can accept.

Appreciate the heads up on the pcap file, I looked for a way to do that originally but not hard enough I suppose...

jbrinker2 ( 2025-07-17 20:12:37 +0000 )edit

add a comment

ESP32-S2 TCP Previous Segment Not Captured

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

ESP32-S2 TCP Previous Segment Not Captured edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

ESP32-S2 TCP Previous Segment Not Captured