This is our old Q&A Site. Please post any new questions and answers at

Can someone help me interpret what's going on this session? It's posted here: line 229 - 238 is an example but there are others in the capture. I'm wondering if the SSL is being fragmented given that it's running over a VPN.

I am having app problems where I get a flood of disconnects throughout the day. Java debug that I get: Error SSL connecting to host:8444: Connection reset Cause: Connection reset and, unknown protocol: socket

asked 15 Oct '13, 17:51

chax8cam's gravatar image

accept rate: 0%

There is a pattern to your trace file. Go to Statistics, Conversations, TCP tab. Sort by relative start and you will notice a pattern (will explain later). But first thing is first. Pkts 229-238, this is an example of an error condition? I don't see the client socket # in your post, so I'm asking. Or are the rejected connections the error condition? There are connections that are refused, that lasts ~5 secs, that lasts ~10 seconds. Which is the error condition?

(16 Oct '13, 05:47) hansangb

There is a pattern to your trace file.

The pattern you detected are (most certainly) service checks from the systems with IP address 172.18.21.x to two SSL servers ( and .56.) These checks run every 60 seconds and are basically TCP connection attempts to check if something is alive and responds. Those are the connections with 7 or 9 frames.

You should exclude those conversations (due to misleading RESETS) and then look if there are any remaining problems.

(16 Oct '13, 07:25) Kurt Knochner ♦

This doesn't look like a fragmentation problem to me. Rather, it looks like a failed SSL session negotiation. Using the display filter " eq 9" isolates the particular TCP stream you referenced (229 - 238). After the three-way handshake, the client ( appears to establish an SSL session with a cached session ID. The server ( responds by sending a server hello and certificate chain, but with a different Session ID. The client responds with a PreMaster secret, but apparently the server doesn't like it because it responds with a TCP RST.

I am not familiar enough with SSL handshakes to understand the failure in detail - I'm sure someone much more knowledgeable will respond with that. But I'm wondering if the server is configured to accept renegotiated SSL sessions?? As a manager of an appliance which terminates SSL sessions, I have the ability to turn that option on/off. I'm wondering if something like that that might be at play here...

(16 Oct '13, 08:31) smp

Thanks SMP...very helpful insight where I can follow-up.

I believe that packets 229-238 is a probe that is failing and continues to do so throughout the capture. In other words the error condition is the failing probe.

I captured a different a client and session that is purported to be a good probe for comparison sake. It shows the client, 172.18.x.x sending the RST as opposed to the server,

I re-posted the original capture and filtered only the client which was in error the entire time.

Appreciate your help!

(16 Oct '13, 08:54) chax8cam
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 15 Oct '13, 17:51

question was seen: 3,139 times

last updated: 16 Oct '13, 08:54

p​o​w​e​r​e​d by O​S​Q​A