The Server seems to be sending FIN Acks for sessions that aren't in the trace, goes on for awhile and then the sessions all resume. Thanks in advance. Uploaded here: https://www.cloudshark.org/captures/86369a51b115 asked 12 Jul '17, 10:31  wiskydelta |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
Can you make the capture at Cloudshark publicly accessible?
Should be accessible now
What do you mean by "the sessions all resume"? Strictly speaking, a TCP session cannot "resume" once finished. An application may resume conversation, using a new TCP session.
Other than that, the first FIN seems to always come from the client side, the server only responds to it.
Not knowing the application case, it is hard to say anything more. I could imagine many clients behind the same NAT device, all of which keep TCP sessions alive for a while after the last application request has been responded, and then close them gracefully (using FIN) on timeout (which is quite a rational approach given the overhead of setting up and especially tearing down a TCP session). You would have to capture for much longer to see several TCP sessions to be established and closed to make some more useful conclusions.
I would consider it some kind of attack to the client, where somebody else would send FINs in its name, expecting that the server would respond with its own FIN, but two things contradict that view:
But there is also a possibility that it is some security device which forges a FIN in the name of the client and handles the consequences smoothly. Can you capture also at client side in parallel to the server side to prove or deny this?
When I say resume, all communications stops and I see a ton of FIN Acks, when they stop then the sessions start establishing correctly again and working. Working on getting a client capture now.