TCP retransmission - false positive

asked 2021-09-25 16:24:27 +0000

sezb51 gravatar image

updated 2021-09-25 16:24:58 +0000

Hello,

sometime during initial TCP three way-handshake we receive a SYN/ACK with a wrong "acknowledge number". Due to that session is RST'ed and new SYN, SYN/ACK, ACK is established:

port 9002 (not OK)
#7  SYN:     Sequence number: 3984327472, Acknowledge number: 0
#9  SYN/ACK: Sequence number: 2091354661, Acknowledge number: 438045413
#11 RST
#13 SYN:     Sequence number: 3109740195, Acknowledge number: 0
#15 SYN/ACK: Sequence number: 2689518568, Acknowledge number: 3109740196
#16 ACK:     Sequence number: 3109740196, Acknowledge number: 2689518569

Interestingly all subsequent packets in such tcp stream are erroneously considered by wireshark as retransmissions.

If we tell wireshark to ignore packets 7-9-11 then wireshark is not fooled anymore and remaining packets get finally decoded properly.

Is this a wireshark known issue where its analysis does not start upon new tcp succesfully establishment ?

Thx, A.

edit retag flag offensive close merge delete

Comments

This should probably be raised as an issue at the Wireshark GitLab page, filling out the information required and attaching a capture that shows the issue.

grahamb gravatar imagegrahamb ( 2021-09-25 19:08:05 +0000 )edit

Did the new SYN use the same source IP/TCP ports? If it is, then Wireshark is interpreting it as the same stream. I am not saying that it is right.

BigFatCat gravatar imageBigFatCat ( 2021-09-25 23:22:37 +0000 )edit

incident reported:

https://gitlab.com/wireshark/wireshar...

sezb51 gravatar imagesezb51 ( 2021-09-26 12:31:45 +0000 )edit
add a comment