Revision history [back]
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.
There there are signs of MTU issue here.
Is it some tunnel on the path (I don't see MAC addresses)?addresses and full frames are not of 1460 Bytes size).
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.
request. It sends Dup ACK to ask for request it again. One Dup ACK is not enough to get Fast Retransmission, BUT the sender should have sent regular Retransmission retransmission based on timer. We don't see any Retransmissions 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 error 500 and connection closes using FINs.
The segments that didn't pass have TCP data length of 1394 Bytes (+ TCP (+TCP header = 32 Bytes + IP header = 20 Bytes) = 1446 Bytes total, excluding Ethernet header which we don't see in the trace (usually 14 (14 Bytes).
So, we observe:
- observe:
- small packets are able to get
through; - through;
- full-sized packets aren't.
It's better to capture on sender side to confirm our conclusions. I assume you'll see observe several Retransmissions of the first big packet.retransmissions.
As for workaround:
workaround:
1) look for ICMP black holes on the path;
path; 2) use ip tcp adjust mss or similar feature to reduce reported MSS.