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

The wireshark for retransmission judgment mechanism

0

hi: my wireshark version is Version 1.8.6 (SVN Rev 48142 from /trunk-1.8) Found in the analysis of the data package software for TCP retransmission judgment problems, can help explain whether the software is how to determine the retransmission.

How do I upload the data packet to the forum?

Thank you.

asked 25 Mar '13, 06:41

mengsunny's gravatar image

mengsunny
11446
accept rate: 0%

You can use http://www.cloudshark.org and post the URL here.

(25 Mar '13, 06:43) Jasper ♦♦
(25 Mar '13, 06:49) mengsunny

Whether the software will only compare the TCP sequence and acknowledgment numbers, rather than see if the TCP data content exists

(25 Mar '13, 06:57) mengsunny

One Answer:

1

Wireshark will compare Sequence and Acknowledge numbers, and will NOT care about what the TCP data content actually is. That's what checksums are for: making sure that the received data in the packet is what the sender was sending out.

By the way, your trace is kinda strange. It shows that port numbers are reused within about 4 seconds from SYN to SYN (Packets 1, 19, 46...). This is not good, which means that the node with IP 202.107.238.218 is probably doing something very wrong. Whatever the reason why the node does, it will most likely lead to chaos.

answered 25 Mar '13, 07:11

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

edited 25 Mar '13, 07:13

Thank you for your explanation, this is a problem being analyzed, found that frequent client to reuse socket, but the server will still accept the connection, communication, there are some problems.

RFC1122 When a connection is closed actively, it MUST linger in TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime). However, it MAY accept a new SYN from the remote TCP to reopen the connection directly from TIME-WAIT state, if it: (1) assigns its initial sequence number for the new connection to be larger than the largest sequence number it used on the previous connection incarnation,and (2) returns to TIME-WAIT state if the SYN turns out to be an old duplicate.

Obviously, my analysis of the problem does not meet this requirement, but can not explain why the connection is established successfully

(25 Mar '13, 07:25) mengsunny

By the way, the client equipment and SSL connection establishment, rather than a real web server

(25 Mar '13, 07:31) mengsunny

Your answer has been converted to a comment as that's how this site works. Please read the FAQ for more information.

(25 Mar '13, 07:35) grahamb ♦