Please explain this TCP Retransmission Sequence

asked 2018-07-19 06:30:02 +0000

BradJ
3 ●1 ●1 ●3

updated 2018-07-19 07:45:35 +0000

Hi All,

I hope I am doing the right thing asking this here. I'm new to all this.

Below is an extract from a pcapng file. I can't attach the file because I don't have enough points. I have googled and googled but I am not a network guy and I am having trouble understanding what wireshark is trying to tell me.

This sequence below repeats over and over. It should just be a big message from .200 to .182 with a 1 byte response, and then a short message from .182 to .200 with a 1 byte response. Is every message in each direction really getting re-transmitted and are the TCP-Dup ACK and TCP-Keep Alive's a problem?

Sorry for the formatting. Happy to re-post in another way if it helps.

edit: capture is hosted on cloudshark here: https://www.cloudshark.org/captures/5...

Thanks in advance, Brad.

1   14:58:25.934858 10.10.10.200    10.10.10.182    TCP 53740 → scp-config(10001) [PSH, ACK] Seq=1 Ack=1 Win=63198 Len=1005 1059

2   14:58:25.934860 10.10.10.200    10.10.10.182    TCP [TCP Retransmission] 53740 → scp-config(10001) [PSH, ACK] Seq=1 Ack=1 Win=63198 Len=1005    1059

3   14:58:25.968185 10.10.10.182    10.10.10.200    TCP scp-config(10001) → 53740 [ACK] Seq=1 Ack=1006 Win=2048 Len=0   60

4   14:58:25.968186 10.10.10.182    10.10.10.200    TCP [TCP Dup ACK 3#1] scp-config(10001) → 53740 [ACK] Seq=1 Ack=1006 Win=2048 Len=0 60

5   14:58:26.024675 10.10.10.182    10.10.10.200    TCP scp-config(10001) → 53740 [PSH, ACK] Seq=1 Ack=1006 Win=2048 Len=1  60

6   14:58:26.024676 10.10.10.182    10.10.10.200    TCP [TCP Keep-Alive] scp-config(10001) → 53740 [PSH, ACK] Seq=1 Ack=1006 Win=2048 Len=1 60

7   14:58:26.074496 10.10.10.200    10.10.10.182    TCP 53740 → scp-config(10001) [ACK] Seq=1006 Ack=2 Win=63197 Len=0  60

8   14:58:26.074497 10.10.10.200    10.10.10.182    TCP [TCP Keep-Alive ACK] 53740 → scp-config(10001) [ACK] Seq=1006 Ack=2 Win=63197 Len=0 60

9   14:58:26.120072 10.10.10.182    10.10.10.200    FMTP    Operational message 89

10  14:58:26.120074 10.10.10.182    10.10.10.200    TCP [TCP Retransmission] scp-config(10001) → 53740 [PSH, ACK] Seq=2 Ack=1006 Win=2048 Len=35    89

11  14:58:26.120075 10.10.10.200    10.10.10.182    TCP 53740 → scp-config(10001) [PSH, ACK] Seq=1006 Ack=37 Win=63162 Len=1    60

12  14:58:26.120075 10.10.10.200    10.10.10.182    TCP [TCP Keep-Alive] 53740 → scp-config(10001) [PSH, ACK] Seq=1006 Ack=37 Win=63162 Len=1   60

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2018-07-19 14:02:20 +0000

Eddi

2379 ●8 ●48 ●59

I start a new answer for the sake of readability.

The "black lines" indicating re-transmissions are a result of your capture setup. As Christian mentioned, you can remove the duplicate packets or use a capture method that does records each frame only once. After the dupes have been removed the trace file reveals two transactions:

1005 bytes from .200 to 182 in frame 1
A Response split over packets 5, 9 and 11 with 1, 35 and 1 byte respectively
Another request in frame 13
Another response in packets 17, 21 and 23

Look at the time differences between frames 1 and 5: the first part of the Response arrives after 89 msec. The last byte of the response is seen 185 msec after the request from .200

The second request is observed 297 msec after the first one. The timing is with 92 resp. 187 msec quite similar.

It totally depends on your application if these responses are fast or slow.

edit flag offensive delete link

add a comment

answered 2018-07-19 07:15:52 +0000

Eddi

2379 ●8 ●48 ●59

Hi Brad

Welcome to ask.wireshark.org. The short extract from the trace file shows a lot of duplicate frames. A good example are frames 1 and 2:

Same source
Same destination
Same sequence numbers
Same length
Nearly same time stamp: both packets are 2 nanoseconds apart.

A look at the IP ID in the IP header would confirm this.

Is it possible, that your capture environment delivered the same packets twice? If you have indeed captured the same packet twice Wireshark will mark this as a retransmission.

I suggest that you go through Jaspers excellent network capture playbook. If your trace file does not contain sensitive data you might be able to share it via cloudshark.

Good Luck

edit flag offensive delete link

Comments

Hi Eddi,

The IP ID in the IP header is identical. The trace was captured on a laptop attached to the spanning port of a switch.

We will run wireshark on one of the machines to see if we get a different view.

edit: capture is hosted on cloudshark here: https://www.cloudshark.org/captures/5...

Brad.

BradJ ( 2018-07-19 07:34:29 +0000 )edit

Alas, I don't have permission to view the file.

Eddi ( 2018-07-19 08:20:15 +0000 )edit

Try now pls..

BradJ ( 2018-07-19 10:24:03 +0000 )edit

Hi please use 'editcap -D' to remove the red herings of duplicated packets. https://www.youtube.com/watch?v=I0BFd...

Christian_R ( 2018-07-19 11:36:59 +0000 )edit

add a comment

Your Answer

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

Add Answer

Please explain this TCP Retransmission Sequence

2 Answers

Comments

Your Answer

Question Tools

Stats

Related questions

Please explain this TCP Retransmission Sequence edit

2 Answers

Comments

Your Answer

Question Tools

Stats

Related questions

Please explain this TCP Retransmission Sequence