 | 1 | initial version |
there are signs of MTU issue here. Is it some tunnel on the path (I don't see MAC 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. It sends Dup ACK to request 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 big timeout (about 30 sec) the server sends error 500 and connection closes using FINs.
The segments that didn't pass have data length of 1394 Bytes (+TCP header = 32 Bytes + IP header = 20 Bytes) = 1446 Bytes total, excluding Ethernet header we don't see in the trace (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 observe several retransmissions.
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.
| | 2 | No.2 Revision |
there There are signs of MTU issue here.
Is it some tunnel on the path (I don't see MAC addresses and full frames are not of 1460 Bytes size).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. request.
It sends Dup ACK to request ask for 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 (14 (usually 14 Bytes).
So, we observe:
- observe:
It's better to capture on sender side to confirm our conclusions. I assume you'll observe see several retransmissions.Retransmissions of the first big packet.
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.
