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

The tcp sequence number altered?

0

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

3 Answers:

3

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

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

0

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

miaohf
5114
accept rate: 0%

0

alt text

alt text

answered 13 Mar '14, 18:33

miaohf's gravatar image

miaohf
5114
accept rate: 0%

edited 13 Mar '14, 18:36