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

Connection timing out

0
1

I'm investigating an intermittent problem involving the transfer of data. An internal client application sends data to a server accessible over the internet. The communication uses SSL.

Recently, the transfer of data has started to fail. Application logs show a 'connection time out' message. Application providers say it's not a software fault. All other internet bound services are operating without issues and this is an isolated issue.

Questions:

  1. What would you look out for in a WireShark capture? Are there any specific filters etc that would be useful in this scenario?
  2. A firewall capture taken during a failed transfer, shows a RST near the end of the capture, from the server 30secs after the previous packet in that conversation. I suspect the timer is controlled by a time out setting in the application but what I don't understand is if thats the case, why would the RST be sent from the remote server and not the client where the application is hosted?

asked 05 Aug '15, 02:17

Brad_101's gravatar image

Brad_101
41●5●8●11
accept rate: 0%

One Answer:

0

Without seeing a capture it's a lot of guesswork but here is my try.

  1. I would start looking whether the TLS handshake was successful and real data transfer was going on.
    An indication is that the tcp payload starts with 17030x Filter: tcp[12,20:2]==50:1703||tcp[12,32:2]==80:1703
  2. If the firewall trace shows a RESET coming from the server exactly 30 seconds after the previous packet then it is likely a timer at the server that is causing the connectin to be closed. But maybe the RST does not really come from the server but from a device in between. Check the ip.ttl of the reset and see if it matches the server's TTLs from previous packets.

Regards Matthias

answered 05 Aug '15, 11:34

mrEEde's gravatar image

mrEEde
3.9k●15●22●70
accept rate: 20%

Thanks Matthias.

Here are two seperate traces captured from firewall during a successful data transfer and during an unsuccessful transfer.

The failure trace is different to the caputre I was referring too previously so the 30 sec time out is different (looks like it's higher in this case).

Success trace = https://drive.google.com/file/d/0BxWWq7ozi-PFZnc2eEFSZnh6blU/view?usp=sharing Failure trace = https://drive.google.com/file/d/0BxWWq7ozi-PFUW4yeUZUcGlBZFU/view?usp=sharing

The TTL on the RST is different to the TTL in previous packets.

For what reason would another device send the RST? Is that normal?

(05 Aug '15, 13:21) Brad_101

The failing trace shows that your firewall resets the connection because the server didn't send a syn_ack within 30 seconds.

So the real problem is that the server does not accept your 4th tcp connection (tcp.stream==3). It -might- be because your client application didn't close the 3rd connection (tcp.stream==2) as it did with tcp.stream=0 of tcp.stream==1.

(05 Aug '15, 14:14) mrEEde

Thanks for the response Matthias.

How do you know that it's the firewall resetting the connection? Is it assumed it's that device because the server hasn't sent a SYN_ACK?

From looking at the success trace, it seems the client didn't send a FIN for streams 5 & 6 either.

Does that change your thoughts in response to your comment in the second paragraph?

(06 Aug '15, 03:46) Brad_101

"How do I know it's the FW sending the RST?" I don't know, I guess from the TTL 64 which is a well known initial ttl value (for linux based systems) - and it would make sense if a firewall resets a connection that never fully established after a certain amount of time.

In the success case the server actively terminates the connections after 15 seconds. I don't know the application protocol so I cannot comment on whether it is good behaviour by the client to keep sessions open if they're no longer needed. And the success case doesn't show another new session attempt while the sessions are still in FINWAIT2 state.

But there are many possibilities why the server doesn't respond to your syn requests.

(06 Aug '15, 04:55) mrEEde