multiple SYN/ACK for one handshake
I have a question about the TCP handshake process.
Recently, I got an intermittent issue on my Openshift pod, below is the tcpdump. From the dump, what I can see is the server pod send back two SYN/ACK for one client SYN, the two SYN/ACK has different SEQ.
I have no idea about how the server returns different SEQ to the client, any one can help me with this? Thanks a lot!
276745 2021-12-13 14:40:59.693787 10.128.2.1 10.128.5.12 TCP 124 60028 → 8080 [SYN] Seq=0 Win=28200 Len=0 MSS=1410 SACK_PERM=1 TSval=1278780542 TSecr=0 WS=128
276747 2021-12-13 14:40:59.693926 10.128.5.12 10.128.2.1 TCP 124 8080 → 60028 [SYN, ACK] Seq=0 Ack=1 Win=27960 Len=0 MSS=1410 SACK_PERM=1 TSval=2347794832 TSecr=1278780542 WS=128
276748 2021-12-13 14:40:59.694005 10.128.5.12 10.128.2.1 TCP 124 [TCP Previous segment not captured] [TCP Port numbers reused] 8080 → 60028 [SYN, ACK] Seq=122 Ack=1 Win=27960 Len=0 MSS=1410 SACK_PERM=1 TSval=2347794832 TSecr=1278780542 WS=128
276749 2021-12-13 14:40:59.694131 10.128.2.1 10.128.5.12 TCP 116 60028 → 8080 [ACK] Seq=1 Ack=1 Win=28288 Len=0 TSval=1278780543 TSecr=2347794832
276750 2021-12-13 14:40:59.694167 10.128.2.1 10.128.5.12 HTTP 1674 POST /docker/sys/tipUpdate HTTP/1.0
276751 2021-12-13 14:40:59.694194 10.128.2.1 10.128.5.12 TCP 116 [TCP Dup ACK 276749#1] 60028 → 8080 [ACK] Seq=1559 Ack=1 Win=28288 Len=0 TSval=1278780543 TSecr=2347794832
No. Time Source Destination Protocol Length Info
276752 2021-12-13 14:40:59.694252 10.128.5.12 10.128.2.1 TCP 104 8080 → 60028 [RST] Seq=1 Win=0 Len=0
276753 2021-12-13 14:40:59.694326 10.128.5.12 10.128.2.1 TCP 104 8080 → 60028 [RST] Seq=1 Win=0 Len=0
276754 2021-12-13 14:40:59.694386 10.128.5.12 10.128.2.1 TCP 104 8080 → 60028 [RST] Seq=1 Win=0 Len=0
304998 2021-12-13 14:41:00.700469 10.128.5.12 10.128.2.1 TCP 124 [TCP Retransmission] [TCP Port numbers reused] 8080 → 60028 [SYN, ACK] Seq=122 Ack=1 Win=27960 Len=0 MSS=1410 SACK_PERM=1 TSval=2347795838 TSecr=1278780542 WS=128
305000 2021-12-13 14:41:00.700586 10.128.5.12 10.128.2.1 TCP 124 [TCP Retransmission] 8080 → 60028 [SYN, ACK] Seq=0 Ack=1 Win=27960 Len=0 MSS=1410 SACK_PERM=1 TSval=2347795838 TSecr=1278780542 WS=128
305001 2021-12-13 14:41:00.700730 10.128.2.1 10.128.5.12 TCP 104 60028 → 8080 [RST] Seq=1 Win=0 Len=0
305002 2021-12-13 14:41:00.700769 10.128.2.1 10.128.5.12 TCP 104 60028 → 8080 [RST] Seq=1 Win=0 Len=0
As ever, attempting to diagnose an issue from a text dump which shows only partial info, e.g. what is the TCP seq. for frame 276750 is difficult. Please consider uploading the (possibly anonymised) capture to a public share and posting a link to it back here. Previoud frames that used the client port 60028 may also be of interest.
The full dump involves too many different client connections, I am interested in the previous frames of the 60028, however, the problem happens intermittently and the tcpdump file is increasing so fast. When this happened, the previous frame has lost already. Does that cause by reuse of previous port 60028, which cause the two different SYN/ACK with different SEQ? here is the exported full dump for 60028 in the exists pcap：http://box.henlife.cn:8080/s/QAe2kZ9JGBq4weq
Is it possible to upload a pcap file?
I can't upload the pcap because it contains some sensitive message, sorry.
Take this as an opportunity to learn to anonymise a capture, e.g., through TraceWrangler