0

I have a client establish new TCP connection then sends request to a server per second. Both client and server are on the same linux box (via loopback interface).

The client periodically reports socket error. After digging the network packets, the error seems related to the TCP problem:

50123 > 7001 [SYN] Seq=0 Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=1326528350 TSecr=0 WS=128 [TCP ACKed lost segment] 7001 > 50123 [ACK] Seq=1 Ack=1834710718 Win=256 Len=0 TSval=1326528350 TSecr=1325798923 SLE=0 SRE=1 50123 > 7001 [RST] Seq=1834710718 Win=0 Len=0

I the above TCP segments, the client first send an TCP SYN to the server. In normal case, server should returns SYN-ACK with ack number=1, but in above snip, server returns ACK with wrong ack number=1834710718. Because the ack number is wrong, client RST the connection.

Any idea about this case?

petertc
  • 2,920

1 Answers1

1

I realize this reply is 8 years overdue.

I have seen the very first SYN from a client get an unexpected server response, an ACK with the wrong sequence number. There is a chance that your server is sending "Challenge ACKs" which are a defense against blind in-window connection disruption attacks as discussed in RFC 5961 (https://datatracker.ietf.org/doc/html/rfc5961).

I have tried to read that RFC which states that its mitigations are appropriate to long lived connections. It's not clear to me why a server responds to the first packet, the one that starts a TCP conversation, with a challenge ACK.

Here's a nice long discussion of these attacks, challenge ACKs and Palo Alto firewall settings that can break connections when a challenge ACK happens: https://www.networkdefenseblog.com/post/wireshark-tcp-challenge-ack

Last but not least, for people trying to interpret wireshark output for this case, set absolute (not relative) sequence numbers in the TCP protocol preferences.

chrisinmtown
  • 121
  • 1
  • 7