Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-08-27 Thread dmccrthy
Hi All, We are having a problem with a Tomcat client getting bad_record_mac exceptions when connecting to a server. Other applications are able to connect to that service so this seems specific to our client. I have included a description of the problem, analysis steps taken/not yet taken,

Re: Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-08-27 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Diarmuid, On 8/27/15 12:08 PM, dmccrthy wrote: We are having a problem with a Tomcat client getting bad_record_mac exceptions when connecting to a server. Other applications are able to connect to that service so this seems specific to our

RE: AW: WebSocket asynchronous reads

2015-08-27 Thread Konstantin Preißer
Hi, -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, August 27, 2015 12:30 AM To: Tomcat Users List users@tomcat.apache.org Subject: Re: AW: WebSocket asynchronous reads On 26/08/2015 12:50, Steffen Heil (Mailinglisten) wrote: Hi Is there a

Re: Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

2015-08-27 Thread dmccrthy
Hi Chris, Thanks for responding so quickly. My apologies, I should have been clearer on the topology. We have a Tomcat instance with a 3rd party web app deployed on it (the Tomcat client) running on Windows 2008 . This connects via HTTPS to a 3rd party service running behind IBM Http Server on

Re: Problems with tomcat-connectors-1.2.41 on 32bit linux

2015-08-27 Thread Falco Schwarz
On Wed, Aug 26, 2015 at 8:13 PM, Rainer Jung rainer.j...@kippdata.de wrote: I added a configure check in http://svn.apache.org/viewvc?view=revisionrevision=1697985 and documented the problem in https://bz.apache.org/bugzilla/show_bug.cgi?id=58285 You might want to cross check.

AW: Connection resets without timeout

2015-08-27 Thread Steffen Heil (Mailinglisten)
Hi For everyone following this thread, here are some conclusions I came up with. First I need to correct myself: I saw FIN/ACK, not FIN/FIN+ACK (at least I could not reproduce that). So when the client program gets closed, the tcp stack of the client sends FIN and the server running tomcat