Ask Your Question
0

TCP Previous segment not captured - TCP Dup ACK

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

abetancourt gravatar image

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

1 Answer

Sort by ยป oldest newest most voted
0

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

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 more

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 gravatar imageabetancourt ( 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 gravatar imagePacket_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 gravatar imageabetancourt ( 2019-03-20 00:17:41 +0000 )edit

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

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

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

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

Seen: 54 times

Last updated: Mar 18