Ask Your Question
0

Sequence numbers for retransmitted packets staying at Zero

asked 2022-08-12 18:55:09 +0000

ajaznawaz gravatar image

updated 2022-08-12 20:36:04 +0000

grahamb gravatar image

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.

edit retag flag offensive close merge delete

Comments

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.

grahamb gravatar imagegrahamb ( 2022-08-12 20:40:40 +0000 )edit

Version 3.6.7 (v3.6.7-0-g4a304d7ec222)

ajaznawaz gravatar imageajaznawaz ( 2022-08-12 21:49:15 +0000 )edit

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.

ajaznawaz gravatar imageajaznawaz ( 2022-08-12 21:53:12 +0000 )edit

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.

grahamb gravatar imagegrahamb ( 2022-08-13 11:58:29 +0000 )edit

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'

ajaznawaz gravatar imageajaznawaz ( 2022-08-13 12:13:30 +0000 )edit

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 gravatar imagegrahamb ( 2022-08-13 20:37:29 +0000 )edit

GrahamB, I am able to share direct, please advise on your preferred method. I checked PM feature here - not available.

ajaznawaz gravatar imageajaznawaz ( 2022-08-14 08:48:36 +0000 )edit

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 gravatar imagegrahamb ( 2022-08-14 11:59:19 +0000 )edit

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.

ajaznawaz gravatar imageajaznawaz ( 2022-08-14 23:26:47 +0000 )edit

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.

grahamb gravatar imagegrahamb ( 2022-08-15 08:21:34 +0000 )edit

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...

ajaznawaz gravatar imageajaznawaz ( 2022-08-15 14:32:40 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2022-09-14 18:10:09 +0000

DavidB gravatar image

I may be missing something here. OP is talking both source ports and sequence numbers. I think we all agree the TCP Port Reuse messages are unneeded / wrong. In first (and most) TCP SYN packets, the TCP Segment Lenth is zero (0). The TCP Segment length determines how the sequence number will increment. As you can see in the flow, the client performs an initial SYN, waits 1 second, then 2 seconds, then 4 seconds - as it attempts to connect to the server. The 4th SYN completes. For each of the initial SYN requests, the Sequence number is and will remain 0 - as there is no TCP Payload. As grahamb implies, I believe the TCP Sequence number will only increment as there is a new TCP payload being sent. If the sender is re-sending a TCP payload, the original SEQ number will be used.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2022-08-12 18:55:09 +0000

Seen: 691 times

Last updated: Sep 14 '22