Hi there, I captured a correct sequence with wireshark V1.12.3 starting with a SYN: 22 23.886574000s 192.168.0.160 192.168.0.2 50000 TCP 60 1027→50000 [SYN] Seq=0 Win=1446 Len=0 MSS=1446 Everything is fine. But when I save this File an reopen it, so the same line is being displayed as: 22 23.886574000s 192.168.0.160 192.168.0.2 50000 TCP 60 [TCP Port numbers reused] 1027→50000 [SYN] Seq=4294967260 Win=1446 Len=0 MSS=1446 with an other sequence number and the Frame is marked as possible erroneous (TCP Port numbers reused). asked 14 Jan '15, 00:04 ClownFerdinand |
2 Answers:
I can reproduce the issue when opening the capture file in Wireshark 1.12.1. The ISN is 0 (absolute value), so it seems the TCP dissector can not properly handle the case of an ISN of 0. Could you file this as a bug on bugs.wireshark.org (referring to this question)? answered 14 Jan '15, 01:47 SYN-bit ♦♦ |
[TCP Port number reused] is diagnosed when you have a SYN packet with the same IP:Port combination for client and server as a previous conversation. The new SYN has a different sequence number, otherwise it would be considered a retransmission of the previous SYN. See packet-tcp.c:
answered 14 Jan '15, 00:13 Jasper ♦♦ This is not the problem. The second line is not a second SYN. Its is the same SYN as in the first line. 1. I captured the sequence: --> copy to first line 2. I save the sequence in a file 3. I opened the file saved in step 2 --> copy to second line (14 Jan '15, 00:21) ClownFerdinand Okay, looks like there are two problems. Wireshark should not save/load anything different than it was captured, and second, it should not mark something as port number reused if it isn't. Can you provide a sample capture? Upload to http://www.cloudshark.org and post the link if you can. (14 Jan '15, 00:24) Jasper ♦♦ Here you are: SYN-Capture On this page, the explanation of the frame is o.k. No "TCP Port numbers reused" issue. But open this file in the wireshark V1.12.3. Than the issue will happen. Thanx in advance Steffen (14 Jan '15, 01:19) ClownFerdinand |
Thanks. The corresponding bug-number is: Bug 10854