A fix is available
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
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