Sequence numbers for retransmitted packets staying at Zero
Clients sends SYN and receives no reply, subsequent retransmissions follow but marked with TCP Port numbers reused message in square brackets by Wireshark. I'm guessing the reuse marking is because sequence numbers did not increment by one for every such retransmission.
If the above is true, and packets don't lie, I was not expecting such b behaviour from the client initiating the request.
What version of Wireshark is being used here? There is current ongoing work in the development branch to improve the TCP analysis output.
As these are retransmissions (due to the server not responding) it's implicit that ports will be reused. Arguably then, there is no need to display the port reused message.
Version 3.6.7 (v3.6.7-0-g4a304d7ec222)
Like I stated in my OP this would be true if the expected behaviour in respect to seq numbers, was that they increment n+1 as each packet for any given stream goes out ...
Are you following me, apologies in advance if I am not explaining clearly.
Why would the sequence number increase for a retransmission? In your capture the server hasn't responded so the client retransmits with the same sequence number.
I hear you GrahamB but then as you stated earlier this is not expected display by Wireshark. My train of thought was how else could it be avoided. This particular example threw a huge curve ball at us this way.
Let me explain. On the server side we were observing proper 'port reuse' messages where some device along the network path was tampering with Src ports.
Hopefully it can be addressed soon, we say 'Packets don't lie', I shall caveat that by adding 'mostly'