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 edited 04 Nov '11, 03:50 showing 5 of 6 show 1 more comments |
2 Answers:
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 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 |
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 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 |
Drop it on CloudShark and post the URL here, so we can all see the capture.
Hi Jaap,
I cannot upload the capture by CloudShark, why?
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.
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
Jimmy, click the "Contact" link over on CloudShark.org and they'll help you get the file uploaded.
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