Some thing wrong when I was send a file with FTP . I captured the network card stream ,and found packet was Tagged retransmission by wireshark. client IP:123.160.53.111 sever IP:172.16.8.61was the server SIP and 221.181.100.222 was VIP. I saw that the packet whichTCP sequence number is 70529 retransmissed in the ftp client. But in the ftp server,the sequence number was altered,and does not seems a retransmissed packed. I was confused,why ? asked 25 Feb '14, 20:53  miaohf edited 25 Feb '14, 23:35 |
3 Answers:
The client is using TCP segmentation offload. Sequence number 70529 at the sender is part of the large segment starting with 67633. There seems to be a NAT device in the path that might not be handling the high packet rate very well. So I suggest you turn off segmentation offload TSO using ethtool -K as described here and see if this circumvents the problem answered 25 Feb '14, 22:04  mrEEde edited 25 Feb '14, 23:19 THANK YOU for your reply, mrEEde. The ACKs (73425,76321,79217) never make it back to the client BECAUSE: the client had never send these packages,maybe the network equipment went wrong,but how it goes ? (25 Feb '14, 22:56) miaohf I just updated my answer with a reference to the ethtool -k to turn off segmentation offload (25 Feb '14, 23:20) mrEEde [[email protected]_3G_FTP_01 miaohf]# ethtool -K eth2 tso off I turned off the TSO,and the problem appears again. The package captured from client as follow,and I can't get the server's package today.
(26 Feb '14, 02:02) miaohf When you change the TCP preferences to relative sequence numbers, you can see how many bytes are actually sent befor the session stalls. Can you see a pattern in multiple transfers? How many bytes go through before the session stalls? (28 Feb '14, 22:47) mrEEde anybody help me ? any advice is expected,thanks. :) (12 Mar '14, 01:47) miaohf "... advice is expected" Diagnosing this with hardcopy pictures of tshark output is not very efficient. For most people here time is a limited resource so could you please post the capture files to http://cloudshark.org This way we can use wireshark - this is what this QA site is about ;-) - to speed up understanding what the problem might be. You might want to use editcap -s 64 to strip off the data part of the packets. (15 Mar '14, 05:49) mrEEde showing 5 of 6 show 1 more comments |
At the server it arrives as the 3rd segment 
The problem is that these ACKs (73425,76321,79217) never make it back to the client 
Also the retransmitted seqments 70529 never show up at the server.
sorry, mrEEde my picture is so big ,and I almost not see your reply on 28 Feb. I'll show you the obsolute sequence number below. answered 12 Mar '14, 18:56 miaohf |
answered 13 Mar '14, 18:33 miaohf edited 13 Mar '14, 18:36 |
It's too awkful for the captured content showing. I'll put the shotscreen picture like below.