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

Delayed FIN and new TCP Session initiated

0

Before I upload the capture I need to anonymize it. But let me post the question first, perhaps someone knows a quick answer.

I've been having problems where clients in China are experiencing performance issues when browsing to a sharepoint website. It redirects, and uses single sign on, then tries to load the page. This last page may stay completely blank (except for the titlebar) for about 90 - 120 seconds, then the entire page loads. Other webpages do not show this symptom.

When analyzing a packet capture I can see that all foreign TCP sessions (towards the internet, not local) have a FIN,ACK packet which is received 90 - 120 seconds after the previous packet ... Then, after the sessions is closed, the client starts a new sessions towards the same external server and then everything looks normal again.

In other words, the delay in FIN,ACK matches exactly the delay in showing the webpage. The re-initiation of the TCP sessions looks like it's trying again to load the webpage.

Could this be caused by a session timeout? Does anyone know if this is 'expected' behavior for some phenomenon I haven't found yet?

asked 24 Oct '14, 04:08

JoepMeloen86's gravatar image

JoepMeloen86
26●6●6●11
accept rate: 50%

2 Answers:

0

I think I figured it out. I thought the answer was a network phenomenon, but you got me thinking it was a client thing. While loading this website, it also loads all kinds of other stuff in the background (like office356.com, microsoftonline.com, sharepoint.com just to name a few).

One of these websites is maps.google.com (don't ask me why, web designers >.<) I saw a recurring pattern that reaching this website (in all captures) failed dramatically with lots of retransmissions and RST packets. The delay on these transmissions went from 3 sec, 6 sec, 12, 3, 6 etc. Adding all these up results in the exact time the website 'chokes' in loading.

So as a test I put all traffic in trough a proxy. This solved the problem, then I manually excluded maps.google.com and the problem returned.

Thanks again for your help.

answered 27 Oct '14, 02:56

JoepMeloen86's gravatar image

JoepMeloen86
26●6●6●11
accept rate: 50%

1

Hi,

It's quite difficult to understand the capture from your description. Where was the capture taken? I assume adjacent to the web server. You really need to trace from the PC as well but I'll have a crack at it.

One reason the above can happen is through the following scenario:

  1. Starting from after completion of the single sign on, the browser starts a TCP connection to the web server
  2. The browser sends a GET for the first page you mention which has a main page containing the Title Bar and a body contains an IFRAME (effectively another web page)
  3. An intervening device (load balancer, firewall or proxy) RESETs the TCP connection, maybe because something in the chain doesn't support Persistent Connections
  4. The RESET gets dropped somewhere (e.g. some firewalls drop RESETs by default) and so the browser believes the TCP connection is still good
  5. The browser sends a GET (in a packet) on the initial (now dead) TCP connection
  6. The TCP Send times out (no ACK received) and so re-sends the GET packet
  7. The TCP stack on the PC retries the operation 4 more times, doubling the timeout each time
  8. The TCP stack on the PC sends a RESET on the dead TCP connection
  9. An intermediate device may translate to the FIN you see in the trace
  10. The TCP stack on the PC returns an error to the browser
  11. The browser starts a new connection (SYN, SYN/ACK, etc.)
  12. Everything bursts back into life

This is similar to a scenario I have in the RPR course I teach and that was based on an eCommerce use case.

The network RTT for China will probably be about 300 ms and so the initial timeout will be 600 ms. The timeout will double with each retry. So the delay will be .6 + 1.2 + 2.4 + 4.8 + 9.6 + 19.2 = 28.8, unfortunately not enough to explain your problem but maybe there are some variations to my theory above.

The trace at the PC is key.

Best regards...Paul

answered 25 Oct '14, 02:31

PaulOfford's gravatar image

PaulOfford
131●28●32●37
accept rate: 11%

Thanks for your elaborate answer Paul. I will have a look to post a part of the capture as soon as possible. (there's a lot of confidential info I don't want on the internet ;) )

I will have a look at you theory as well. Ill get back with a reply soon.

(27 Oct '14, 01:54) JoepMeloen86