First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

Why am I getting TCP Previous Segment not captured?

I'm working with a new embedded device and having performance issues.

I'm suspecting the devices tcp/ip stack, but need to understand the capture better.

I'm hoping someone here can give me some insight...

I see the "TCP Previous segment not captured" and after that, a retransmission occurs, causing a 1 to 2 second delay. The device needs to stream and I'm trying to understand what's going on.

Any help / insight would be greatly appreciated.

J.

https://www.cloudshark.org/captures/0...

martinjplajp's avatar
1
martinjplajp
asked 2018-08-07 16:14:17 +0000
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

2 Answers

1

We see "TCP Previous segment not captured" message when Wireshark observes a packet that has TCP SEQ number bigger than we expected in this TCP stream.

For example look at packet No. 134.

It has SEQ of 11701, but we expected SEQ of 10241 (previous packet in this stream had SEQ 10165, and we add segment lenght of 76, so we wanted to see 10165+76). So exactly 1460 Bytes are missing (one-MSS TCP packet).

In your case the packet was actually lost somewhere because we observe subsequent Dup ACKs and Retransmission (receiver and sender reacting to packet loss).

To have an ability to dig deeper we need to know some additional details about network environment you're capturing in and where is the capture point located. And also please capture TCP 3-way handshake if possible (beginning of the connection).

Packet_vlad's avatar
1.1k
Packet_vlad
answered 2018-08-08 11:02:14 +0000, updated 2018-08-08 11:05:15 +0000
edit flag offensive 0 remove flag delete link

Comments

Thank you for your response.

The setup for this device is a dedicated 100 mb ethernet direct link to the device from the PC via a usb-ethernet adapter, so no traffic from any other device should be present. Capture point is on the PC communicating with the device. (192.168.2.2)

Here is a capture from the power on of the device, thru a transfer that exhibits the issue.

https://www.cloudshark.org/captures/2...

Thanks again :)

martinjplajp's avatar martinjplajp (2018-08-08 12:31:15 +0000) edit

The link to Pcap is corrupted this time..

Packet_vlad's avatar Packet_vlad (2018-08-09 09:58:16 +0000) edit

Sorry about that. Try this one. https://www.cloudshark.org/captures/2...

martinjplajp's avatar martinjplajp (2018-08-09 12:25:29 +0000) edit

So your device is 192.168.2.105? The one periodically sending small bursts of data?

There's one confusing part in the trace - pair of packets 271+272, 316+317 etc. We have the same source IP and dest IP, BUT mac addresses are rotating. How is that?

Packet_vlad's avatar Packet_vlad (2018-08-10 13:04:40 +0000) edit

I see what you are saying. Does that have anything to do with the 2nd packet being a retransmission? Is there an easy wait to get the mac address of my PC ethernet adapter to verify? The embedded device is relatively new and may have issues in the Stack, so nothing is off the table here.

martinjplajp's avatar martinjplajp (2018-08-10 21:08:09 +0000) edit
add a comment see more comments
0

Was related to incorrect stack configuration on the embedded device.

martinjplajp's avatar
1
martinjplajp
answered 2018-08-16 13:33:13 +0000
edit flag offensive 0 remove flag delete link

Comments

Hello,

Could you please elaborate what was the lwip stack configuration issue?

Facing something similar.

Thanks

Vivan5's avatar Vivan5 (2022-07-02 14:28:18 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer