IBM Support

PM16441: CONNECTIONS USING ATTLS REMAIN IN LAST_ACK STATE AND SYN PACKETS FOR NEW CONNECTIONS ARE DROPPED

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Some connections using ATTLS remain indefinitely in LAST-ACK
    state.
    
    An additional symptom may be the failure of connection requests
    that match ip addreses and port numbers of connections that
    are in LAST_ACK.  This is because the client side believes the
    connections were closed and reuses the same ip address and port
    again in a later connection request but TCPIP on the z/OS finds
    the connection in its connection table and can not process a
    new connection with the same set of ip addresses and port
    numbers.
    
    additional symptom:
    abend0c4 in EZBIPOUT referencing an invalid RTOP. Ctrace
    systcpip with option TCP will show application using
    AT-TLS and trying to send FIN packet after TCPIP TCB has been
    freed.
    verification steps for the ezbipout abend scenario:
    10000036 153FC1E0 1532A000 1532A1A0 00F69580 00D5 XXXXXX
    000C4000 Ab Iu
    RSA  1532A668  Prev 1B2FCEE0  Next 1532A830  Mod EZBPFCLS
    RSA  1532A838  Prev 1532A668  Next 1532AC18  Mod EZBPFCLO
    RSA  1532AC20  Prev 1532A838  Next 1532B238  Mod EZBTCSTR
    RSA  1532B240  Prev 1532AC20  Next 00000000  Mod EZBIPOUT
     3184 bytes were used
    .
    where XXXXXX is the jobname of the AT-TLS enabled application.
    
    Verification Steps:
    1) use NETSTAT CONN, or from a dump use IP TCPIPCS CONN to
       locate ATTLS connections in LAST_ACK state.
    2) If a connection resulting in LAST_ACK state can be
       captured in a Packet trace, it will show an ending sequence
       similar to the following (from a SESSION report) at the end
       of the connection:
    
    AP   .   2419516557  531752581 65259 90 0.000198 10:18:32.771926
    AP   +    531752581 2419516647 65535 45 0.001305 10:18:32.773231
    AP   +   2419516647  531752626 65214 66 0.000461 10:18:32.773692
    AP F I . 2419516713  531752626 65214 29 0.000055 10:18:32.773747
    AP   O a  531752626 2419516743 65535  0 0.000027 10:18:32.773774
    AP   O .  531752626 2419516743 65535 29 0.000443 10:18:32.774217
    A R  I a 2419516743  531752655     0  0 0.000254 10:18:32.774471
    AP F O ?  531752655 2419516743 65535  0 0.000090 10:18:32.774561
      R  I a 2419516743 2419516743     0  0 0.000227 10:18:32.774788
    
    3) Dump of TCPIP on the system with the LAST_ACK connections
       will show inflight recorder information similar to the
       following for the TCBs with LAST_ACK state
       from: IP TCPIPCS TCB(applicationname DETAIL
    
       IFR0E:TellApp IFR0F:procfin IFR13:tcusd IFR01:tcsnd
       IFR50:tlprcfin IFR19:tcsfn IFR01:tcsnd IFR51:RstIgnore
       IFR84:drop4 IFRAF:* IFR3D:tcfcl IFR2F:tcgtb
    
    
    KEYWORDS: LASTACK LAST-ACK ATTLS SYN
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of Communications Server for       *
    *                 z/OS Version 1 Release(s) 11 and 12 IP:      *
    *                 ATTLS                                        *
    ****************************************************************
    * PROBLEM DESCRIPTION: ATTLS Connections hang in LAST-ACK      *
    *                      state.                                  *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The problem is due to timing and may be summarized as
    follows:
    
    1. ATTLS received an SSL close notify alert plus FIN from
       a client connection.  An SSL close notify alert was
       internally generated and returned to the client connection.
    
    2. The local application issued a shutdown() call.
    
    3. A reset was returned from the client.  ATTLS ignored the
       reset.  The local application issued a close() call.  The
       connection remained hung in LAST-ACK state.
    
    4. A second timing scenario had also been proved to cause the
       ATTLS connection to hang in LAST-ACK state.  In this case,
       the reset from the client is processed just after the close()
       call from the application.  The reset is incorrectly
       ignored, resulting in the hang.
    +-------------------------------------------------------------+
    + 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. Module EZBTCSTR has been modified to request that the
       TCB be freed during close processing if the TCB is for
       ATTLS, is in LAST_ACK state, and a reset was previously
       ignored.
    
    2. Module EZBTCRD currently ignores a reset for an ATTLS
       connection if the following conditions are true:
    
       - ATTLS received an SSL alert.
       - The remote side sent a FIN.
       - There are no outstanding write requests by the appl.
    
       EZBTCRD will be modified to add another condition which
       must be also true before ignoring the reset:
    
       - The appl has not completed close.
    
    3. Module EZBTLMST has been included for maintenance
       purposes.
    
    * Cross Reference between External and Internal Names
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM16441

  • Reported component name

    TCP/IP V3 MVS

  • Reported component ID

    5655HAL00

  • Reported release

    1B0

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2010-06-14

  • Closed date

    2010-07-28

  • Last modified date

    2010-11-02

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

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

    UK59396 UK59397

Modules/Macros

  • EZBTCRD  EZBTCSTR EZBTLMST
    

Fix information

  • Fixed component name

    TCP/IP V3 MVS

  • Fixed component ID

    5655HAL00

Applicable component levels

  • R1B0 PSY UK59396

       UP10/10/06 P F010

  • R1C0 PSY UK59397

       UP10/10/06 P F010

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.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1B0","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSCY4DZ","label":"DO NOT USE"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1B0","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 November 2010