This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

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's gravatar image

miaohf
5114
accept rate: 0%

edited 25 Feb '14, 23:35

It's too awkful for the captured content showing. I'll put the shotscreen picture like below. alt text

alt text

(25 Feb '14, 20:58) miaohf

The client is using TCP segmentation offload. Sequence number 70529 at the sender is part of the large segment starting with 67633. alt text At the server it arrives as the 3rd segment alt text The problem is that these ACKs (73425,76321,79217) never make it back to the client alt text Also the retransmitted seqments 70529 never show up at the server.

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

permanent link

answered 25 Feb '14, 22:04

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

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.

alt text

(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

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.

permanent link

answered 12 Mar '14, 18:56

miaohf's gravatar image

miaohf
5114
accept rate: 0%

alt text

alt text

permanent link

answered 13 Mar '14, 18:33

miaohf's gravatar image

miaohf
5114
accept rate: 0%

edited 13 Mar '14, 18:36

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×104
×53

question asked: 25 Feb '14, 20:53

question was seen: 4,058 times

last updated: 15 Mar '14, 05:49

p​o​w​e​r​e​d by O​S​Q​A