Revision history  [back]

When viewing TCP conversations, the flow appears backwards. I would expect "Address A" to be the source and "Address B" to be destination like it is most of the time. In both examples, I captured TCP SYN & SYN ACKs, but one example shows the correct direction and the other is reversed.

Edit: links to files at the bottom. I also found another example with where the same source and dest as the backwards example which shows correctly. My thought is that Wireshark is seeing the source port higher than the destination port so it orders them as such.

Win10 x64 Wireshark Version 3.2.7 (v3.2.7-0-gfb6522d84a3a)

Backwards:

Correct:

Edit: Correct with same source and dest as the backwards one:

Backwards cap: https://www.dropbox.com/s/wpeyc0nui6ih674/backwards.pcapng?dl=0

Not backwards cap: https://www.dropbox.com/s/3as7qeabusyuu6f/not_backwards_same_src_dst.pcapng?dl=0

Not backwards with same src/dst as original: https://www.dropbox.com/s/0nxed4bwb87xb69/not_backwards.pcapng?dl=0

When viewing TCP conversations, the flow appears backwards. I would expect "Address A" to be the source and "Address B" to be destination like it is most of the time. In both examples, I captured TCP SYN & SYN ACKs, but one example shows the correct direction and the other is reversed.

Edit: links to files at Unfortunately I can't upload the bottom. I also found another example where captures as a new member, but those are the same source and dest as only 2 packets in the backwards example shows correctly. My thought is that Wireshark is seeing the source port higher than the destination port so it orders them as such.files.

Win10 x64 Wireshark Version 3.2.7 (v3.2.7-0-gfb6522d84a3a)

Backwards:

Correct: