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'
What is the expected display?
I think we can agree that [TCP Retransmission] is expected, these are retransmitted packets.
The [TCP Port numbers reused] is debatable. The port numbers are being reused, but as consequence of retransmission.
Could you share a link to the capture so I can try it with the Wireshark development version to see how that handles this situation?
GrahamB, I am able to share direct, please advise on your preferred method. I checked PM feature here - not available.
Use a public file share and post a link back here. If you are concerned about leaking private info use an anonymisation tool such as TraceWrangler before uploading the file..
GrahamB, I'm having second thoughts on sharing such data which has the potential of being a career limiting move. If there is anything specific in the way of screenshots taken from the capture the please do let me know. Meanwhile I will look into TraceWrangler as suggested. Thank you.
If you export only the 4 SYN packets, then unless the remote IP or local and gateway MAC addresses are considered secret, it should be safe to share those 4 packets.
Hi GrahamB. used tracewrangler, took time as I use a mac, so someone else did it for me. impressive tool. thanks for sharing !
cap file can be dowloaded here using onedrive link:
https://1drv.ms/u/s!ApSvUszXYued31NaR...
The current dev version shows the same TCP analysis flags, both retransmission and port reuse.
I suppose that's good, or no GrahamB ..
The application in question here is Global Protect from PaloAlto, but anyway, is it the OS's TCP stack that assigns the Src port or does that come from the application itself ..?
In terms of next steps here is that WS bug or something else ..?, Incidentally today I was watching some of Hangsang's videos on the tube and he confirmed that in some cases packets do 'lie', so one must tread carefully and alway ask the question 'why?'