PK17249: NEW SSL CONNECTIONS HANG, EXISTING CONNECTIONS ARE OKAY.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Telnet accepts a connection over a secure port. SSL services are
  called to start the SSL handshake.  The client does not send SSL
  data, but instead sends data such that SSL does not fail the
  handshake and Telnet does not timeout the connection.  This
  causes the connection to stay in the SSL handshake for more than
  SCANINTERVAL seconds.  EZBTTTSI sends a Timemark to the
  connection, then tries to close the connection.  EZBTTCLS
  requests the CVB lock in exclusive mode for the SSL connection.
  EZBTTTSI has the TCFGCVB lock shared.  If Telnet tries to obtain
  the TCFGCVB lock exclusive for another task, such as cleaning up
  CVBs, then all connection requests on that port will hang
  until the SSL connection is terminated.
  .
  VERIFICATION STEPS:
  1) New SSL connections will fail.  Netstat may show connections
  in CloseWait
  2) TCPIPCS Lock report will show contention:
  Lock@    Ducb@    Status               Name
  7F0AD310 18284000 Held Shr             TPDBTCFG
  7F3D80D8 15B51000 Held Shr  EnqH       TCFGCVB
           18284000 Wait Shr
           1827B000 Wait Excl
  7EFF2060 17DC9000 Held Shr  EnqH       TCVB
           15B51000 Wait Excl
  3) Reviewing the DUCBs will show EZBTTTSI is waiting for the
  TCVB lock and holds the TCFGCVB lock.  The DUCB waiting for
  TCFGCVB exclusive will cause connections to hang.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of Communications Server           *
  *                 using z/OS Version 1 Release 4, Version 1    *
  *                 Release 5, Version 1 Release 6, and          *
  *                 Version 1 Release 7 IP Telnet facilities     *
  *                 using SSL connections.                       *
  ****************************************************************
  * PROBLEM DESCRIPTION: New Telnet SSL connections cannot       *
  *                      be started; existing connections are    *
  *                      okay.                                   *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem may be summarized as follows:
  
  1. A TN3270 client attempted a connection over a secure
     port.  The Telnet server waited for the client Hello
     during the SSL negotiation process.  A Telnet server
     utility task held the CVB lock for this connection
     in shared mode while waiting for the Hello:
  
     EZBTTTSK -> EZBTTSMT
  
  2. Instead of sending an SSL Hello, the client continued to
     send a x'FFF1' sequence (NOP) to the Telnet server.  This
     prevented SSLTIMEOUT from timing out the SSL handshake.
  
  3. Eventually TIMEMARK/SCANINTERVAL processing caused the
     Telnet server to send a Timemark to the client.  A Timemark
     response was not returned by the client and EZBTTTSI
     issued a TNCLOSE macroinstruction to drop the
     connection.  Module EZBTTCLS was called, and requested
     the CVB lock in exclusive mode.  The EZBTTTSI thread was
     suspended.
  
     EZBTTTSI -> EZBTTCLS
  
  4. New requests for SSL connections could not be processed.
     These requests required the TCFGCVB lock which was held
     by the suspended EZBTTTSI thread.
  +-------------------------------------------------------------+
  + Please check our Communications Server for OS/390 homepages +
  + for common networking tips and fixes.  The URL for these    +
  + homepages can be found in Informational APAR II11334.       +
  +-------------------------------------------------------------+
  

Problem conclusion

• To resolve this problem, the following changes have been
  made:
  
  1. Control block EZBZCVB has been updated to include a
     new flag which indicates that the Telnet server is
     waiting for an SSL Hello from the client.
  
  3. Module EZBTTTSI is the Telnet server TIMEMARK processor.
     This module has been changed to bypass connections (CVBs)
     which are waiting for the client to send an SSL Hello.
  
  2. Module EZBTTSMT has been changed to set the new CVB
     based flag before waiting for a client SSL Hello.
     The flag is also reset after the wait expires.
  
  4. Module EZBTTSSD has been included for maintenance
     purposes only.
  
  * Cross Reference between External and Internal Names
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UK10652 UK10653 UK10654 UK10655

Modules/Macros

• EZBTTSMT EZBTTSSD EZBTTTSI EZBZCVB
  

Fix information

• Fixed component name

  TCP/IP V3 MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R140 PSY UK10652

     UP06/02/15 P F602 Ž

• R150 PSY UK10653

     UP06/02/15 P F602 Ž

• R160 PSY UK10654

     UP06/02/15 P F602 Ž

• R170 PSY UK10655

     UP06/02/15 P F602 Ž

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.