Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] RST in connection after webserver upgrade. Pleasehelp anal

From: "Small, James" <JSmall@xxxxxxxxxxxxxx>
Date: Thu, 16 Nov 2006 09:02:03 -0500

Jeroen,

 

From what you included below, it looks like after the upgrade, the web server responds with an extra/extraneous FIN segment.  In the before scenario, you have a proper shutdown – FIN/ACK & ACK (close one direction), FIN/ACK & ACK (close other direction).  In the after scenario you have a FIN/ACK from the web server followed by a FIN/ACK from the load balancer.  It looks like the web server is then sending another FIN/ACK.  Next it appears that the load balancer is responding to the first FIN/ACK with an ACK and then responds to the second FIN/ACK with a RST.

 

Now as to why that’s happening is another question…

 

That’s my interpretation anyway…hope it helps,

  --Jim

 

 

We have 2 IBM IHS webservers (Apache 2.0.x) with a Avaya loadbalancers on top. The loadbalancers does every

5 seconds a healthcheck with an GET / HTTP/1.1 request. Now the health check works and this is the flow:

 

Webserver1: 10.132.32.97

Loadbalancer: 10.132.32.124

 


No.     Time        Source                Destination           Protocol Info
     28 6.281687    10.132.32.124         10.132.32.97          TCP      63264 > 50110 [SYN] Seq=0 Len=0
     29 6.281764    10.132.32.97          10.132.32.124         TCP      50110 > 63264 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460
     30 6.284956    10.132.32.124         10.132.32.97          TCP      63264 > 50110 [ACK] Seq=1 Ack=1 Win=8192 Len=0
     31 6.285819    10.132.32.124         10.132.32.97          HTTP     GET / HTTP/1.1
     32 6.286340    10.132.32.97          10.132.32.124          HTTP     HTTP/1.1 200 OK (text/html)
     33 6.289605    10.132.32.124         10.132.32.97          TCP      63264 > 50110 [FIN, ACK] Seq=90 Ack=605 Win=8192 Len=0
     34 6.289649    10.132.32.97          10.132.32.124         TCP      50110 > 63264 [ACK] Seq=605 Ack=91 Win=32768 Len=0
     35 6.289691    10.132.32.97          10.132.32.124         TCP      50110 > 63264 [FIN, ACK] Seq=605 Ack=91 Win=32768 Len=0
     36 6.293661    10.132.32.124         10.132.32.97          TCP      [TCP Dup ACK 33#1] 63264 > 50110 [ACK] Seq=91 Ack=605 Win=8192 Len=0
     37 6.294571    10.132.32.124          10.132.32.97          TCP      63264 > 50110 [ACK] Seq=91 Ack=606 Win=8192 Len=0

We needed to upgrade our webserver to a new IBM IHS release (Apache 2.0.47) and now the health check doesn't work and Avaya marks

the webserver as down. Because the Avaya needs a HTTP 200 OK response AND a good closed tcp connection.

And as you can see, there is not a nice closed session. The loadbalancer send a RST to close the connection.

Can anybody see why?

 

No.     Time        Source                Destination           Protocol Info
     51 10.000206   10.132.32.124         10.132.32.97          TCP      63378 > 50110 [SYN] Seq=0 Len=0
     52 10.000345   10.132.32.97          10.132.32.124         TCP      50110 > 63378 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460
     53 10.003637   10.132.32.124         10.132.32.97          TCP      63378 > 50110 [ACK] Seq=1 Ack=1 Win=8192 Len=0
     54 10.004307   10.132.32.124         10.132.32.97          HTTP     GET / HTTP/1.1
     55 10.004993   10.132.32.97          10.132.32.124          HTTP     HTTP/1.1 200 OK (text/html)
     56 10.005111   10.132.32.97          10.132.32.124         TCP      50110 > 63378 [FIN, ACK] Seq=624 Ack=90 Win=32768 Len=0
     57 10.014761   10.132.32.124         10.132.32.97          TCP      63378 > 50110 [FIN, ACK] Seq=90 Ack=624 Win=8192 Len=0
     58 10.014820    10.132.32.97          10.132.32.124         TCP      50110 > 63378 [FIN, ACK] Seq=624 Ack=91 Win=32768 Len=0
     59 10.016232   10.132.32.124         10.132.32.97          TCP      63378 > 50110 [ACK] Seq=91 Ack=625 Win=8192 Len=0
     71 12.180680   10.132.32.124         10.132.32.97          TCP      63378 > 50110 [RST] Seq=92 Len=0