Application crashes, host is sending RST back to server, captures of both

asked 2019-11-28 21:13:13 +0000

JJRtree81 gravatar image

updated 2019-11-28 22:22:38 +0000

I have an application that is crashing. This is a guess, but I think the application expects the database connection to be still opened, but it's not, and then it crashes.

From the captures it appears the computer that the application is running on sends a RST back to the server, but I haven't been able to figure out why.

I have attached captures of both server and computer at the time the error happened.

I think frame 40329 in the computer capture matches up to 5211 in the server capture.

Any help is greatly appreciated.

computer capture

server capture

edit retag flag offensive close merge delete

Comments

How does the client normally close a connection to the server?
Looking at the server capture, the last activity before 5211 are 2626 and 2627 which look good.
Then 168 seconds later comes the reset in 5211.

Then are plenty of other connections in the server capture which much longer times between TCP packets.

bubbasnmp gravatar imagebubbasnmp ( 2019-11-29 04:54:59 +0000 )edit

From the trace files we can spot two different RSTs. One is RST after receiving a FIN And the other one comes in the middle of a session after a gap of 168 s. I think this second case RSTs are not the cause of the application crash they are more or less the indication of it.

Christian_R gravatar imageChristian_R ( 2019-11-30 23:29:44 +0000 )edit

Can anyone confirm what I think I'm seeing. Packet in frame 40329 in the computer capture is a RST because the computer did not receive the packet in frame 2627 in the server capture.

JJRtree81 gravatar imageJJRtree81 ( 2019-12-06 22:50:31 +0000 )edit

Server display filter:

(ip.addr eq 10.49.44.58 and ip.addr eq 192.168.222.225) and (tcp.port eq 6536 and tcp.port eq 9471)

Computer display filter:

(ip.addr eq 10.129.229.41 and ip.addr eq 192.168.222.225) and (tcp.port eq 52103 and tcp.port eq 9471)



They are in a different order because of where the capture was done but I don't see a missing packet.

bubbasnmp gravatar imagebubbasnmp ( 2019-12-07 04:17:41 +0000 )edit

It might be easier to see comparing a flow graph for each capture.
Check the "Limit to display filter" box and set Flow type: TCP Flows.

Or add the a column to the packet list ip.id and see that the packets are there, just a different order.

bubbasnmp gravatar imagebubbasnmp ( 2019-12-07 05:27:09 +0000 )edit