PQ70771: CONNECTIONS ARE IDLE IN A CLOSEWAIT STATE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• NETSTAT CONN will show that there are connections in a CLOSWAIT
  state.  This happens when TCPIP processes an inbound FIN and the
  window size goes to zero.  The FIN is acked, but if there is
  unsent data, TCPIP will not try to send it.  The data buffers
  will stay allocated in storage.  If there are many connections
  in this state, especially if they are connections with the
  FTP server (which utilize 180K ESCA CSM buffers), you could
  see a storage problem.  This could cause CSM to be constrained.
  .
  KEYWORDS: CLOSEWAIT close wait idle ftp netstat
  .
  ADDITIONAL SYMPTOMS:
  If this causes CSM to be constrained, TRACERTE could
  fail with:
  EZA0486E RawIPOpen(ICMP): No more space for data currently
  available (8539)
  OMPROUTE could also see:
  EZZ7840I SENDTO() ERROR, ERRNO=1122:EDC8122I NO BUFFER SPACE
  AVAILABLE, ERRNO2=74420324
  .
  VERIFICATION STEPS:
  Looking at the hung TCB in a dump of TCPIP, you will see
  that the TCB_SND_WND is zero.  The TCB_TIMING PROBE will
  not be initialized (will not have a TID eyecatcher).  You
  can determine how long the connection has been idle from
  the TCB_LAST_ACTIVITY timestamp.
  .
  A packet trace will show that a FIN is received with a
  window size of zero.
  

Local fix

• Issue a NETSTAT CONN.  If there are connections in a closwait
  state, use the drop command to drop the connection.  This will
  also clean up storage associated with the connection.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of the IBM Communications Server   *
  *                 for z/OS Version 1 Release 2 & 4 IP          *
  ****************************************************************
  * PROBLEM DESCRIPTION: TCP connections remain in CLOSEWAIT     *
  *                      state indefinitely.                     *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  TCP connections may remain in CLOSEWAIT state indefinitely.  The
  connection will have no data in the pipe so the retransmit timer
  will not be running.  The send queue will have data to be sent,
  the window size will be zero, and the probe timer will be off.
  The connection has no timers running that will cause any data
  on the send queue to be sent, so there will be no outbound data
  packets sent unless the remote end sends a non-zero window
  update.  The probe timer should be started when the window
  goes to zero, the pipe is empty, and there is data on the send
  queue.
  This problem only occurs when the inbound TCP layer receives a
  zero window update and a FIN during the same pass.  This can
  occur in the same packet or separate packets that arrive over
  the network interface in the same read operation.
  The specific case where this problem was reported involved a
  TCPIP stack that allowed the remote socket to close without
  reading all of the data.  The connection should have been reset
  by the remote end when the socket was closed.  The fact that
  the remote socket was closed means there will never be an
  unsolicited window update received on the local side of the
  connection.
  +-------------------------------------------------------------+
  + 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

• TCSNDINT has been amended to convert a request to send an ACK
  to a PROBE request when there is no data in the pipe, the window
  is zero, there is data on the send queue and there is no probe
  timer already running.
  
  * Cross Reference between External and Internal Names
  

Temporary fix

Comments

APAR Information

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

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

  UQ74446 UQ74447 PQ72868

Modules/Macros

• EZBTCFWR EZBTCSND TCSNDINT
  

Fix information

• Fixed component name

  TCP/IP V3 MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R120 PSY UQ74446

     UP03/03/17 P F303

• R140 PSY UQ74447

     UP03/03/17 P F303

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.