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

What is causing “Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host."

0

We are getting this error when performing a save within the application. It is a click once application and the data is stored in the cloud. The application is normally open for 2+ hours before performing the save. Recently upgraded to Juniper switches (this error did not happen prior to this). I have a Wireshark capture file but need assistance analyzing it for possible causes for the error. Any help greatly appreciated.

asked 10 Nov '14, 12:51

Carey's gravatar image

Carey
14●1●1●5
accept rate: 0%

edited 10 Nov '14, 13:02

Thanks guys for the information provided. I wanted to post the link to the anonymized capture file from the client...

https://drive.google.com/file/d/0Bz2uKfNM3FQfMV81UGVpUDBpSjA/view?usp=sharing

(13 Nov '14, 14:29) Carey

If you have opportunity please review client capture file and see if it provides clues to the issue. thx again!

(14 Nov '14, 08:36) Carey

One Answer:

2

What is causing "Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host"

well, let's first talk about the issue. Based on that message (and some information found through Google), I assume that a TCP session was closed by one side, either by sending a FIN or a RESET (more likely).

So, what can cause this? Many things:

  • a bug in the software
  • intended behavior of the server (or client) software, like some kind of timeout
  • a problem with a device between client/server
  • a firewall/loadbalancer/WAN accelerator as you hit a session limit and/or a session timeout on that device
  • etc.
  • etc.

As you can see, there are a few good reasons for that behavior. Without a capture file taken near the client and in parallel near the server, you won't be able to figure out what exactly is causing the problem. In such a case, it's also a good idea to look at the server logs (if you have access to those logs).

Regards
Kurt

answered 11 Nov '14, 14:31

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

1

I think you need to consider exactly what changes were made implementing the new Juniper switches. I expect that you may have introduced a stateful aspect into the connection between client and server. This is likely to be that " firewall/loadbalancer/WAN accelerator " function that Kurt refers to. This may simply be a function of say having an ACL with a "Established" check in the switch.

If that is the case you should be able to either set a longer session timer, or see if you can configure your application to use TCP keep-alive to maintain session state.

(11 Nov '14, 19:09) martyvis

The ISP had changed as well and this error did not happen prior to that. We found the ISP had some sort of "inactivity timeout" for the TCP port (appx. 90 seconds). Thanks again for the input.

(15 Dec '14, 07:53) Carey