I have problems with transfers between a Lotus Notes client (192.168.1.11) and server (192.168.2.21). I see some ACKed unseen segments, retransmissions, duplicate ACKs etc and after a while the transfer goes down. Any ideas why this might be? https://www.cloudshark.org/captures/b59f824f3caf Appreciate any feedback that can help me find the problem :-) asked 30 Mar '17, 23:30  cepheidlight |
2 Answers:
The trace shows IP fragmented packets arriving at the trace point. The ip.len of those arriving packets is 1420 bytes so we know this is the bottleneck link's MTU size. As the following fragments do not show up at the trace point , and probably won't make it to the destination - this will certainly cause trouble. The inbound SYN_ACK's MSS is set to 1400 indicating a (FW/VPN) device has adjusted the original MSS from 1460 to 1400. Unfortunately this was not enough to avoid fragmentation. a reduction to 1380 bytes would have been required to avoid fragmentation. If fixing this device is not in your scope you can add a host route and reduce the MTU size to 1420 to circumvent this problem. Regards Matthias . answered 02 Apr '17, 11:19  mrEEde |
There are many packets that were on the wire but not captured by your sniffer. Those are the "unseen" segments and they do not affect any real life problem that you may have. About 64 KB of data was missing in this way. Here is the order of events at the end of the TCP connections in this trace file (using the connection with client port 50310 as the example):
It would appear that your throughput is being affected by those regular 60 second gaps, which are caused by those timeouts before the client's Final. The connection closure mechanism is not performed correctly from the client's viewpoint, causing it to issue the Reset, but we have a new connection operating during this period and so flow isn't affected. It could be that some of the server's ACK packets are being lost. However, there are no indications of any of the server's data packets being lost. Could it be possible that your client doesn't properly understand D-SACKs? Once it has received one, it goes into limbo until issuing the Final? You could test this by disabling the Selective ACK capability at either your client or server (only need to disable at one end). Without SACK support, the D-SACKs should become ordinary ACKs and may allow your client to continue the flow on the original TCP connection. You'll still suffer the 300ms RTO, but that's better than the additional 60 second timeouts to the Finals. Google it to find the relevant Registry settings for your Windows client. Another thing you could try is either:
answered 01 Apr '17, 23:04  Philst edited 02 Apr '17, 05:59 I think there is a problem with wireshark's calculation of relative sequence numbers. Packet Numbver 16 shows the 'real' sequence number instead of the relative one. This is causing the 'previous segment not captured' messages (02 Apr '17, 00:05) mrEEde There really are lots of packets not captured by the sniffer @mrEEde. I also used a commercial packet analysis tool to examine this trace file. (02 Apr '17, 06:01) Philst 1 Wireshark makes a mess of the relative sequence numbers in packet 16 because the packet is marked as an IP fragment and the code that adjusts sequence numbers to be relative from the sequence base (SYN or first packet in the stream) is not run on a fragmented packet. I've raised a Bugzilla item for this, bug 13550. (02 Apr '17, 09:07) grahamb ♦ |
The ACKed unseen segments is an indice that you have not captured those packets. But there RST packets, those could be part of the problem. But it is hard to tell why they were sent, maybe they are application releated.