PH53670: SYN/ACK BEING SENT WITH THE WRONG SEQUENCE NUMBER

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Where the sending of an ACK in response to an invalid packet
  does not adjust the sequence number if the SYN flag is still set
  in the TCP header. The SYN/ACK with the wrong sequence number
  causes the peer to send a RST.
  
  From Case:
  The packet traces show there is some type of firewall or proxy
  device between HAGA and KOBE.  We determine this because the
  Ip_Id value are different for the same connection in HAGA and
  KOBE.  The traces also show the initial SYN packet is being
  retransmitted in the NG and the OK traces from HAGA and only 1
  SYN is reaching KOBE.
  
  I have formatted the packet trace in a session report, and also
  used the full report to get the timestamp values and added them
  to the session data.  The NG trace from KOBE shows the SYN
  arrive inbound with a timestamp value of CE0C0DAC.  The SYN/ACK
  is sent outbound with timestamp value of CE0C0F04 and an echo
  value of CE0C0DAC.  The next inbound packet is an ACK for the
  SYN/ACK, however the timestamp value is CE0C026F which is less
  than the last timestamp value on the SYN packet.  This causes
  the ACK packet to be dropped and TCPIP sends a packet with the
  current SEQ/ACK values of the connection.  This send does not
  turn off the SYN flag because it has not yet been ACKed, but it
  also fails to back the sequence number up by 1 to account for
  the SYN bit being on.  When this packet is received by the proxy
  device it sends a RST packet back to KOBE because the packet
  matches an existing connection but has the SYN bit with a
  sequence number that does not match the initial sequence number.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users of the IBM Communications Server for z/OS 2.5 and  *
  * 3.1 IP                                                       *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * TCP connection is reset after server sends an ACK to an      *
  * invalid packet while in SYNRCVD state.                       *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Apply the PTF                                                *
  ****************************************************************
  After the server side receives a SYN for a new connection
  request it sets its state
  to SYNRCVD and sends an ACK with the SYN flag set (the SYN ACK).
  The server then
  receives an unexpected (invalid) packet instead of the expect
  ACK to the SYN ACK.
  This causes the server to respond with a DUP ACK but the SYN
  flag is still set due to the
  server being in SYNRCVD state. However, the server fails to set
  the tcp header sequence
  number to the correct value for this DUP ACK with the SYN flag
  set.
  This SYN ACK with the wrong sequence number
  causes the peer to send a RST.
  

Problem conclusion

• Modified EZBTCRD to set the sequence number to the correct value
  when the tcp state is SYNRCVD and a DUP ACK is being sent due to
  an unacceptable timestamp on an inbound packet.
  

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:

  UI92045 UI92046

Modules/Macros

• EZBTCRD
  

Fix information

• Fixed component name

  TCP/IP MVS

• Fixed component ID

  5655HAL00

Applicable component levels

• R310 PSY UI92046

     UP23/07/15 P F307

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.