TCPIP CONNECTIONS CAN GET STUCK IN FIN-WAIT-2

 
 APAR Identifier ...... PI73495      Last Changed ........ 17/09/26
 TCPIP CONNECTIONS CAN GET STUCK IN FIN-WAIT-2
 
 Symptom ...... IN INCORROUT         Status ........... CLOSED  PER
 Severity ................... 3      Date Closed ......... 17/02/09
 Component .......... 5735FAL00      Duplicate of ........
 Reported Release ......... 630      Fixed Release ............ 999
 Component Name TCP/IP V2 FOR V      Special Notice
 Current Target Date ..              Flags
 SCP ...................
 Platform ............
 
 Status Detail: SHIPMENT - Packaged solution is available for
                           shipment.
 
 PE PTF List:
 
 PTF List:
 Release 540   : UI44561 available 17/02/10 (1000 )
 Release 620   : UI44533 available 17/02/10 (1000 )
 Release 630   : UI44534 available 17/02/10 (1000 )
 Release 640   : UI44535 available 17/02/10 (1701 )
 
 Parent APAR:
 Child APAR list:
 
 ERROR DESCRIPTION:
 When a secure connection is closed, there is a possibility that
 a TCB (connection structure) with FIN-WAIT-2 status will not be
 released and will stay around forever until TCPIP is restarted.
 The problem occurs when TCPIP has already sent a FIN packet to
 close out the connection, but it never receives the FIN packet
 back from the peer, which results in the connection never being
 fully closed.
 
 LOCAL FIX:
 
 PROBLEM SUMMARY:
 ****************************************************************
 * USERS AFFECTED: All users of the z/VM TCP/IP                 *
 ****************************************************************
 * PROBLEM DESCRIPTION:                                         *
 ****************************************************************
 * RECOMMENDATION: APPLY PTF                                    *
 ****************************************************************
 When a secure connection is closed, there is a possibility that
 a TCB (connection structure) with FIN-WAIT-2 status will not be
 released and will stay around forever until TCPIP is restarted.
 The problem occurs when TCPIP has already sent a FIN packet to
 close out the connection, but it never receives the FIN packet
 back from the peer, which results in the connection never being
 fully closed.
 
 PROBLEM CONCLUSION:
 When a secure connection is established, there are three
 connection blocks (TCBs) that are used.  One is the network
 facing TCB and the other two are used for the connections
 between the SSL server and TCP/IP.  The code has been updated
 so that each of the non-network facing TCBs are updated to
 store the address of the TCB for the other half of the
 connection thus allowing both halves to be closed together.
 The specific updates are as follows:
 
 TCBASTY and TCTCB: TcbType is updated to use SslOtherCn to
 store the TCB address for the other half of the connection.
 
 TCPSSL and T6PSSL: When connecting a SOCKE_SSL socket, each of
 the TCBs will be updated to store the other's address. This will
 allow both sides of the connection to be found.
 
 TCPUP: When a reset request is received for a secure
 connection, ensure that the other half of connection is also
 closed in order to release the whole connection.
 
 TCMON: When dealing with the TCB information, if SslOtherCn
 is not nil, then get the ConnectionName and pass it to the
 caller in the SslOtherCn field instead of the pointer to the
 TCB.
 
 TEMPORARY FIX:
 
 COMMENTS:
  **** PE17/06/27 FIX IN ERROR. SEE APAR PI83658  FOR DESCRIPTION
 
 MODULES/MACROS:
 CMNETST  TCBASTY  TCMON    TCPSSL   TCPUP    TCTCB    T6PSSL
 
 SRLS:
 NONE
 
 RTN CODES:
 
 CIRCUMVENTION:
 
 MESSAGE TO SUBMITTER: