Hang to Remote Host When No Packet Traffic for Long Duration

 
 APAR Identifier ...... PQ79752      Last Changed ........ 03/10/30
 HANG TO REMOTE HOST WHEN NO PACKET TRAFFIC FOR LONG DURATION
 
 Symptom ...... IN INCORROUT         Status ........... CLOSED  PER
 Severity ................... 3      Date Closed ......... 03/10/24
 Component .......... 5735FAL00      Duplicate of ........
 Reported Release ......... 430      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 3A0   : UQ81490 available 03/10/29 (1000 )
 Release 420   : UQ81491 available 03/10/29 (1000 )
 Release 430   : UQ81492 available 03/10/29 (1000 )
 Release 440   : UQ81493 available 03/10/29 (1000 )
 
 Parent APAR:
 Child APAR list:
 
 ERROR DESCRIPTION:
 System hangs occur after a long period when no packet traffic
 is passed between the z/VM TCP/IP server and a remote host.
 Trapping the problem revealed that timestamps in the TCP/IP
 packets become wrapped; this causes packets to become
 backed-up, and results in the hang condition.
 
 LOCAL FIX:
 
 PROBLEM SUMMARY:
 ****************************************************************
 * USERS AFFECTED: Users with TCP connections that are idle     *
 *                 (i.e., do not transmit or receive any        *
 *                 packets) for more than about 18.2 hours      *
 ****************************************************************
 * PROBLEM DESCRIPTION:                                         *
 ****************************************************************
 * RECOMMENDATION: APPLY PTF                                    *
 ****************************************************************
 The TCP timestamps used by z/VM TCP/IP employ units of 16
 microseconds. As a result, after about 18.2 hours, the time
 stamp value wraps. If two consecutive segments are time stamped
 more than 18.2 hours apart, the second segment will be dropped
 (because its time stamp appears to be out of date).
 Retransmissions of the segment will also be dropped until a
 further 18.2 hours elapses.
 
 PROBLEM CONCLUSION:
 Code has been changed to use time stamps that are in millisecond
 units, allowing 64 times as much time (about 48.5 days) before
 the time stamp value wraps. The problem still exists, but is
 considerably less likely to occur because of the reduced
 precision of the time stamp values.
 
 TEMPORARY FIX:
 
 COMMENTS:
 
 MODULES/MACROS:   FPTCPDOW FPTCPUP  TCPDOWN  TCPIP    TCROUND
 
 SRLS:      NONE
 
 RTN CODES:
 
 CIRCUMVENTION:
 
 MESSAGE TO SUBMITTER: