It's all about the answers!

Ask a question

Should rfc1323 be 1 (related to: Remote host closed connection during handshake)?


Kevin Ramer (4.5k8183200) | asked Sep 16 '14, 12:30 p.m.
edited Sep 16 '14, 4:51 p.m.
Ok, I'm dredging up old work items here as we're somewhat at a loss.  Our RTC clients are getting variations of errors mentioned on ( comment 19 )
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=195587

Reading the APAR suggests we set rfc1323 to 0 to try alleviate this issue.  However, examining the interface shows that it already is.

Environment:  AIX 6100-07-05-1228, CLM 4.0.7 in WebSphere 8.5.5.2 (base).   Several IP on the same interface ( unchanged since forever )  The only new in our environment is CLM 4.0.7 all in WebSphere

The interface is 1000/full and recommendations are for rfc1323 to be "on" (i.e. 1)

Anyone have any wisdom to share ?

cf: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=328380




Comments
Donald Nong commented Sep 16 '14, 8:59 p.m.

I think you will need to capture network trace and analyze it to confirm whether the issue is the same as mentioned in comment 19 of WI 195587 .


Kevin Ramer commented Sep 17 '14, 10:23 a.m. | edited Sep 17 '14, 10:27 a.m.

My LPAR has the fix mentioned.

 APAR= IV14297  SER=
 TCP RETRANSMIT PROCESSING IS VERY SLOW
 APPLIES TO  AIX 6100-07

 instfix -ik IV14297
    All filesets for IV14297 were found.

One answer



permanent link
Kevin Ramer (4.5k8183200) | answered Sep 17 '14, 4:53 p.m.
I'm going to put some findings here as they won't fit in a comment.....
For those of us that know about SPoRT, I searched all the current SPoRT Tomcat logs for occurrences of the SSLHandshakeException and found them not too many days after we released our newly minted 4.0.7/WebSphere out to the wild.   I then searched SPoRT logs from the older setups and only found the SSLHandshakeException on connection attempts to the one lone WebSphere we had at the time ( as far back as April 2014 )

In our WebSphere logs we can sometimes see complaints of distrust of an SSL certificate, but it does not reference the configured default certificate, rather the WebSphere created "default" certificate.    Said another way, our NodeDefaultKeystore has 3 items:  Automatically created ssl and root certificate(s) and an installed certificate which is configured on the SSL Settings as the server and client certificate.   I verified this was also the case in our previous WebSphere configuration; now it is similar across all.   Thus a possible cause is that on occasion, the wrong certificate is handed out and it doesn't pass muster.

I think the solution would be to remove that "default" certificate and possibly the root certificate, but I am waiting to be advised via the PMR I created.


Your answer


Register or to post your answer.