Skip to content

TCP: Fix extra "TCP port numbers reused" with missing SYN

John Thacker requested to merge johnthacker/wireshark:tcp_syn_ack_no_syn into master

Handle a few cases where we get a SYN-ACK that strongly indicates a new conversation, but we are missing the SYN.

There's at least one annoying edge case that we didn't handle previously and still don't handle - A --> B SYN A <-- B SYN-ACK ... no response quickly enough for B A <-- B SYN-ACK with new SEQ-NR for B (instead of retransmission ?) A --> B ACK (B's first SYN-ACK sequence number)

and then B just accepts the conversation as ESTABLISHED and goes on with the first proposed sequence number instead of issuing a RST and the handshake starting over. Most of the time there's a RST in this situation (#17616 (closed)). We could wait until we get a RST, but then what would we do if the capture doesn't have the RST? (Since we're already talking about captures that are missing packets from at least one side.)

We definitely don't want to add TCP port numbers reused to the TCP analysis after the first pass.

Follow up to 56ea9816 which did the SYN case.

Fix #19771 (closed)

Merge request reports