After the handshaking process is successfully completed,client sent request and server sends response,this request-reponse business worked seamleesly for one hour After a hour client sent a request ,server sent the response,but client did not acknowledge for all tcp segments sent by the server due to network issues at client. So server does retransmission for 20 seconds finally it sends [RST/ACK] client after sometimes when network comes back initiates a new request again successfully,server send RST immediately with previous failed request (sequence,acknowedgement) pair. I have attached pcap from the when the server sends the response,client acknowledges for few packets and fails to acknowledge for few , What I could not understand is why server sends RST when a new request is made succesfully asked 03 Dec '15, 06:22  saimadan edited 03 Dec '15, 07:54 |
One Answer:
Looks like a perfect network exchange to me. What ever happens seems to be happening at the application level, and is reflected in the packet exchanges you've seen. Make sure that the client and server applications can get synchronized after network issues. answered 03 Dec '15, 07:35  Jaap ♦ can you please help me understand this behaviour,why server sends a RST when a client is able to make a successful request(i'm novice in networking ,i have just started using wireshark) (03 Dec '15, 07:58) saimadan 1 I am not sure I can see that
Because in your capture, the (probably) server rejects, by sending an RST, a mid-session packet, not a new request to establish a TCP session. I guess that what confuses you is that you can see "Seq=1" in the packet you think is a new session-establishment request. The background is such that the tcp sequence numbers actually do not start from 1: they start from a random number, and only the difference between the values used in each direction is important for the protocol. For convenience of reading, Wireshark by default shows these differences (called "relative sequence numbers") instead of the real (absolute) values. And if it does not know the absolute sequence number of the initial packet of a direction of a session because that packet is missing in the capture, it uses as "relative 1" the absolute Seq value of the first packet of a direction of a session which is available in the capture. In our case, the Seq number does not change (no payload bytes have been transmitted) between the very first packet in the capture and the packet (frame) No. 31 which you confused to be a new session establishment request. So as Jaap wrote, the exchange is perfect - in the sense that the server knows that some packets have been irrecoverably lost, so it sends a RST to any attempt of the client to continue using that session, which is the correct behaviour. For the tcp client, reception of a packet with RST flag set is an indication that something went wrong, and it informs its client application about that. The client application then has to take appropriate measures based on that information. How exactly a given application deals with information about failure of a connection is beyond scope of network protocol analysis. An attempt of the client to establish a new tcp session would look the following in Wireshark: the initial packet would show SYN in the packet list pane, and the Syn bit in TCP flags in packet dissection pane would be 1. The presence of Syn=1 in the packet indicates to the recipient of that packet (the server) that this packet is an opening one for a new session, and also to Wireshark that it should take the sequence number of that packet as relative 1 for the new tcp session even if another tcp session was previously using the same pair of sockets (IP address:port). (03 Dec '15, 09:37) sindy |
You forgot to add a question. What you've posted is a statement. And you forgot to post a capture (anonymized using TraceWrangler so that tcp payload and real IP addresses would not be leaked if you consider it necessary) somewhere and provide a link to it. Analysis by text log, especially when you've allowed tshark to replace TCP information by payload information where the latter is available, is close to impossible.
I have attached pcap file,i have just started using wireshark a week back,so i didn't know we can anonymize the actual details