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

why the client resend whole message to server?

0

client:any browser,PC(windows os) server:firewall->F5->IHS->WAS In my case,a http request will be hanged by WAS for 10 min.Somtimes,When WAS hang the request for about 5 min,client(PC) will resend the whole message to server.I've used httpwatch and fiddler to see the resent message,but can't catch any resent info.And wireshark can catch the resent info. The resent time decided by the F5's idle-time settings.When the idle-time changed,the resent interval time changed.They(F5) told me the idle-time is to break off the connection between the client and the server. The info with resent message is:

No.  Time        Source          Destination     Protocol Info 
  75 6.247420    36.0.135.56     60.208.131.87   AJP13    AJP13 Error?[Unreassembled Packet [incorrect TCP checksum]] 
  76 6.247540    36.0.135.56     60.208.131.87   AJP13    AJP13 Error?[Unreassembled Packet [incorrect TCP checksum]] 
  77 6.250121    60.208.131.87   36.0.135.56     TCP      8009 > 54398 [ACK] Seq=1 Ack=1628 Win=16506 Len=0
5223 200.517228  60.208.131.87   36.0.135.56     TCP      8009 > 54388 [RST, ACK] Seq=1 Ack=1 Win=16333 Len=0
5224 200.517230  60.208.131.87   36.0.135.56     TCP      8009 > 54389 [RST, ACK] Seq=1 Ack=1 Win=15368 Len=0
5225 200.517230  60.208.131.87   36.0.135.56     TCP      8009 > 54390 [RST, ACK] Seq=1 Ack=1 Win=15487 Len=0
5226 200.517336  60.208.131.87   36.0.135.56     TCP      8009 > 54393 [RST, ACK] Seq=1 Ack=1 Win=14503 Len=0
5227 200.517337  60.208.131.87   36.0.135.56     TCP      8009 > 54394 [RST, ACK] Seq=1 Ack=1 Win=14347 Len=0
5228 200.517337  60.208.131.87   36.0.135.56     TCP      8009 > 54395 [RST, ACK] Seq=1 Ack=1 Win=14208 Len=0
5229 200.517337  60.208.131.87   36.0.135.56     TCP      8009 > 54396 [RST, ACK] Seq=1 Ack=1 Win=14455 Len=0
7044 249.113874  60.208.131.87   36.0.135.56     TCP      8009 > 54398 [RST, ACK] Seq=1 Ack=1628 Win=16506 Len=0
7078 249.119338  36.0.135.56     60.208.131.87   TCP      54530 > 8009 [SYN] Seq=0 Win=8192 [TCP CHECKSUM INCORRECT] Len=0 MSS=1460 WS=2
7079 249.123288  60.208.131.87   36.0.135.56     TCP      8009 > 54530 [SYN, ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 WS=0
7080 249.123401  36.0.135.56     60.208.131.87   TCP      54530 > 8009 [ACK] Seq=1 Ack=1 Win=65700 [TCP CHECKSUM INCORRECT] Len=0
7081 249.123912  36.0.135.56     60.208.131.87   AJP13    AJP13 Error?[Unreassembled Packet [incorrect TCP checksum]] 
7082 249.124121  36.0.135.56     60.208.131.87   TCP      54531 > 8009 [SYN] Seq=0 Win=8192 [TCP CHECKSUM INCORRECT] Len=0 MSS=1460 WS=2
7083 249.126055  60.208.131.87   36.0.135.56     TCP      8009 > 54531 [SYN, ACK] Seq=0 Ack=1 Win=4380 Len=0 MSS=1460 WS=0
7084 249.126057  60.208.131.87   36.0.135.56     AJP13    AJP13 Error?
7085 249.126195  36.0.135.56     60.208.131.87   TCP      54531 > 8009 [ACK] Seq=1 Ack=1 Win=65700 [TCP CHECKSUM INCORRECT] Len=0
7086 249.126865  36.0.135.56     60.208.131.87   AJP13    AJP13 Error?[Unreassembled Packet [incorrect TCP checksum]] 
7087 249.127037  36.0.135.56     60.208.131.87   AJP13    AJP13 Error?[Unreassembled Packet [incorrect TCP checksum]] 
7088 249.129194  60.208.131.87   36.0.135.56     TCP      8009 > 54530 [ACK] Seq=147 Ack=158 Win=4470 Len=0
7089 249.129195  60.208.131.87   36.0.135.56     AJP13    AJP13 Error?
7090 249.130538  36.0.135.56     60.208.131.87   AJP13    AJP13 Error?[Unreassembled Packet [incorrect TCP checksum]] 
7094 249.134976  60.208.131.87   36.0.135.56     TCP      8009 > 54531 [ACK] Seq=147 Ack=158 Win=4470 Len=0
7096 249.134977  60.208.131.87   36.0.135.56     TCP      [TCP ACKed lost segment] 8009 > 54531 [ACK] Seq=147 Ack=1785 Win=6164 Len=0
7108 249.155169  60.208.131.87   36.0.135.56     TCP      [TCP segment of a reassembled PDU]
7109 249.187292  36.0.135.56     60.208.131.87   AJP13    AJP13 Error?[Unreassembled Packet [incorrect TCP checksum]] 
7110 249.187292  36.0.135.56     60.208.131.87   AJP13    AJP13 Error?[Unreassembled Packet [incorrect TCP checksum]] 
7111 249.192339  60.208.131.87   36.0.135.56     TCP      [TCP segment of a reassembled PDU]
7112 249.192341  60.208.131.87   36.0.135.56     TCP      [TCP segment of a reassembled PDU]
7115 249.208616  36.0.135.56     60.208.131.87   AJP13    AJP13 Error?[Unreassembled Packet [incorrect TCP checksum]] 
7116 249.209016  36.0.135.56     60.208.131.87   AJP13    AJP13 Error?[Unreassembled Packet [incorrect TCP checksum]] 
7117 249.212176  60.208.131.87   36.0.135.56     TCP      [TCP segment of a reassembled PDU]
7118 249.212178  60.208.131.87   36.0.135.56     TCP      [TCP segment of a reassembled PDU]
7134 249.414204  36.0.135.56     60.208.131.87   TCP      54530 > 8009 [ACK] Seq=1421 Ack=538 Win=65160 [TCP CHECKSUM INCORRECT] Len=0
7135 249.414210  36.0.135.56     60.208.131.87   TCP      54531 > 8009 [ACK] Seq=3050 Ack=1600 Win=65700 [TCP CHECKSUM INCORRECT] Len=0

In this case,F5's idle-time was 240s.The interval time between 77 and 7044 was about 240s. The top three line happened when the browser post normal.From 7044,it happend when the client resent. In my case,the WAS must hang every normal request,but the resent message happened sometimes. I found that,we can see a message like this just when the client resent: 7044 249.113874 60.208.131.87 36.0.135.56 TCP 8009 > 54398 [RST, ACK] Seq=1 Ack=1628 Win=16506 Len=0

My question:Why the client resent the whole message(included the same form data) to server?

ps:I apologize for my pool English.:)

asked 13 Sep '12, 23:48

msworder's gravatar image

msworder
1●1●1●2
accept rate: 0%

edited 14 Sep '12, 00:45

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k●9●57●245

One Answer:

0

I assume the trace was taken on the client PC.

As the client gets no answer from the server for a long time, the F5 actively closes the connection due to it's idle timer in its tcp profile. This is why you see the "RST" packets. This closes the tcp connection on the client and the client decides to try a again by opening new connections to the server.

The interesting part would be to look at the server side of the F5 and check why there is no response to the requests. Does the WAS get the request? Does it send a response that does not arrive at the F5 or does the F5 not forward the response.

answered 14 Sep '12, 00:53

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

There are some problem in our applications.Sometimes it would take more than 5 min to deal with some request.So F5 would get no response from WAS until our app finished it's work. If client PC took the trace,why it wasn't happened every time? We made our app sleep for 10 min with no response to F5 when it get a request,and used some PCs with diffrent windows OS and diffrent browsers to test.For each test,we sent a request after a 5 min waiting nothing was done.We found that the resent happened sometimes.

(14 Sep '12, 01:53) msworder

Sounds to me like this needs some thorough investigation with traces being made at different points in the chain. You then need to compare the results for the different scenarios that you describe (when clients do resend the request, when clients don't resend the request, when the WAS server does respond).

(14 Sep '12, 03:13) SYN-bit ♦♦