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

TCP SYN/SYN ACK/PSH ACK/ACK

0

Dear Wireshark,

After the TCP connection established, the client program sent Packet #7 to the server to check the settings. The server replied Packet #8 (included the setting data) and Packet #9 (ACK) to the client. Since the client received Packet #8, it sent Packet #10 (ACK) to the server.

The sequence number of Packet #8 is 1, and the data length is 6, so the sequence number of the next packet sent by the server should be 7 (1+6). But in the WireShark log file as you can see, the sequence number of Packet #9 is still 1, not 7. Therefore the client will abandon Packet #9 since Packet #9 is not the ACK packet which the client expected to receive. So the client will re-transmit Packet #11 to the server, and the sequence number in the Packet #12 is 7, which is the correct ACK packet.

This symptom happened after every packet sent from the client.

Best Regards, Jimmy

asked 04 Nov '11, 03:35

Jimmy's gravatar image

Jimmy
1112
accept rate: 0%

edited 04 Nov '11, 03:50

1

Drop it on CloudShark and post the URL here, so we can all see the capture.

(05 Nov '11, 02:54) Jaap ♦

Hi Jaap,

I cannot upload the capture by CloudShark, why?

Jimmy

(06 Nov '11, 19:17) Jimmy

Why? What what? Why you cannot upload the capture to CloudShark? Ask the CloudShark people. You cannot upload because you're not allowed, and why do we need to see the capture? There are some strange items in your story. The devil is in the details here, which the capture can expose.

(08 Nov '11, 01:49) Jaap ♦

It just shows "Upload in progress... Please wait." Can you provide your e-mail, then I can send the capture to you if you think it is ok. Thanks.

Jimmy

(08 Nov '11, 02:12) Jimmy

Jimmy, click the "Contact" link over on CloudShark.org and they'll help you get the file uploaded.

(08 Nov '11, 06:44) zachad

Zachad,

It's the problem of IE. It's ok when I use the Firefox. The capture has been uploaded and the file name is Mitisubishi and Juggernaut Wireshark 10-6-2011. Thanks.

Jimmy

(08 Nov '11, 23:33) Jimmy
showing 5 of 6 show 1 more comments

2 Answers:

0

I guess that's not about wireshark but about your client bugs, but still have you checked the 'relative sequence numbers' option in TCP protocol settings?

answered 08 Nov '11, 23:11

ShomeaX's gravatar image

ShomeaX
736
accept rate: 0%

http://cloudshark.org/captures/da0e06834b57 So, is this post just for the bugs of Wireshark? Thanks.

Jimmy

(09 Nov '11, 19:58) Jimmy

of course no, sorry.

(09 Nov '11, 23:36) ShomeaX

0

looks to me that both server and client do send data immediately upon connection.

that is server spits '00vP1x0d' string (#8) BEFORE it sends the ACK (#9) to client's '00vPx0d' data (#7). client ACKs (#10) its data and respond with retransmission (#11) for out-of-order ACK he just saw (#9). of course, server ACKs retransmission with duplicate ACK (#12).

next, the same story continues with #14/#15 packet and so on.

everybody operate according to RFC, the client/server program should not see any duplicate data. the only drawback is that bandwidth is used not effectively. what exactly your question is?

answered 09 Nov '11, 23:36

ShomeaX's gravatar image

ShomeaX
736
accept rate: 0%

The problem is happened in Packet #9 because this scenario will be produced in every packet sent from the client. The first time ACK is always not correct in sequence number.

Jimmy

(09 Nov '11, 23:49) Jimmy

at application level, e.g. sockets, this should not be a problem, both duplicate ACK and retransmitted packet must be silently ignored. are you writting/debugging kernel mode driver? what is your operation system, programming language, used networking libraries - provide more info.

(10 Nov '11, 01:02) ShomeaX