TCP Previous segment not captured - TCP Dup ACK

asked 2019-03-17 19:47:47 +0000

abetancourt
3 ●1 ●1 ●3

updated 2019-03-17 22:37:17 +0000

Hi all,

I am sending a request to an API but the data does not arrive completely. The data is XML sent through HTTP. In this file there is a capture: request-01.pcap. Two requests were made, and only the answer is seen with an error 500 in both cases.

In the capture you can see the messages "TCP Previous segment not captured" and "TCP Dup ACK".

The log of the request is in the file curl-01.log. There is this message: "HTTP error before end of send, stop sending".

When I send a smaller amount of XML data, all data is received at the destination. This is the capture: request-02.pcap. Two requests are sent and in the capture both requests and both responses are seen. The log of the request is here: curl-02.log. This time the message is different: "Upload completely sent off: 237 out of 237 bytes".

Does anyone have an idea why the server does not receive the complete request and why the errors "TCP Previous segment not captured" and "TCP Dup ACK" occur?

Thanks in advance.

edit retag flag offensive close merge delete

add a comment

answered 2019-03-18 07:38:28 +0000

Packet_vlad

1055 ●5 ●75 ●32 http://packettrain.net

updated 2019-03-18 07:42:11 +0000

There are signs of MTU issue here. Is it some tunnel on the path (I don't see MAC addresses)?

The traces are captured on (close to) server side. In the first trace the server doesn't get the first packet out of two-packets request. It sends Dup ACK to ask for it again. One Dup ACK is not enough to get Fast Retransmission, BUT the sender should have sent regular Retransmission based on timer. We don't see any Retransmissions though. This are signs of retransmitted packets got dropped on the path too.

After quite a big timeout (about 30 sec) the server sends Error 500 and connection closes using FINs.

The segments that didn't pass have TCP data length of 1394 Bytes (+ TCP header = 32 Bytes + IP header = 20 Bytes) = 1446 Bytes total, excluding Ethernet header which we don't see in the trace (usually 14 Bytes).

So, we observe:

small packets are able to get through;
full-sized packets aren't.

It's better to capture on sender side to confirm our conclusions. I assume you'll see several Retransmissions of the first big packet.

As for workaround:

1) look for ICMP black holes on the path;

2) use ip tcp adjust mss or similar feature to reduce reported MSS.

edit flag offensive delete link

Comments

Hi Vlad. Thanks for your answer.

I confirm the following:
- There is an IPsec tunnel between the client and the server.
- The traces are captured close to server side.
- There are several retransmissions from the sender. This is the capture from the client side: client-side.pcap.

I will review the workarounds that you mention.

abetancourt ( 2019-03-18 13:03:50 +0000 )edit

Agree, client trace confirms assumptions made before.

1) We don't see any ICMP Packet too big messages (probable ICMP blackhole - tunnel entry router).

2) Packet 8 was split on the wire into 2 smaller packets (parts) to fit 1500 Bytes maximum Ethernet frame size.

The first big packet (part) got dropped before tunnel, the second smaller part made it through. All subsequent retransmitted big parts also got dropped.

Check tunnel endpoint router for the ACLs/rules that prevent ICMP packets from being sent.

Packet_vlad ( 2019-03-18 15:19:27 +0000 )edit

Hi Vlad,

You were right about the MTU issue.

I gradually decreased the MTU on the computer that was making the requests. When the value reached 1444 all packets arrived successfully at the destination. This link was very helpful: How to determine the proper MTU size with ICMP pings.

Thank you so much. You are the best!

abetancourt ( 2019-03-20 00:17:41 +0000 )edit

Hi, thanks for the update and you're welcome!

Packet_vlad ( 2019-03-20 07:18:03 +0000 )edit

add a comment

TCP Previous segment not captured - TCP Dup ACK

1 Answer

Comments

Your Answer

Question Tools

Stats

TCP Previous segment not captured - TCP Dup ACK edit

1 Answer

Comments

Your Answer

Question Tools

Stats

TCP Previous segment not captured - TCP Dup ACK