First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

loads of TCP Retransmission, TCP Out-Of-Order, TCP Dups

Hi, Having an issue trying to sort out why Im getting smashed with TCP Retransmission, TCP Out-Of-Order, TCP Dups. Also seeing loads of NBSS Continuation Message. This has been stripped down to 2 laptops and a switch and router - Router on a stick. ZBWL disabled. Host Firewalls not blocking. Just a file copy between 2 laptops on the different VLANs. Have tried a pacp with 2 laptops on same VLAN and just the Switch, still loads of black packets. MTUs in this simple (cutdown) setup are 1500--Pcap has 1500+14 ethernet header.

Any info on how I need to start to work my way through this please? Thanks

Link to pacp (28mb sanitised): link text

2022-08-17-18-31-35.png

dave47's avatar
1
dave47
asked 2022-08-15 07:42:01 +0000, updated 2022-08-17 10:10:47 +0000
edit flag offensive 0 remove flag close merge delete

Comments

As ever, sharing a capture file through a publicly accessible file share makes looking at the SO MUCH easier.

Jaap's avatar Jaap (2022-08-15 07:59:37 +0000) edit
more
  • delete

Are any of the packets making it through, I mean from point A to point B ..? It sounds like maybe some are, but just wanted to make sure.

ajaznawaz's avatar ajaznawaz (2022-08-15 10:56:26 +0000) edit
more
  • delete

Yes, the file transfer actually succeeds.

dave47's avatar dave47 (2022-08-15 22:51:40 +0000) edit
more
  • delete

Updated with a screen-shoot and pcap link This pcap is of a file transfer - the sanitization has removed a lot of size.

dave47's avatar dave47 (2022-08-17 10:13:27 +0000) edit
more
  • delete
add a comment see more comments

1 Answer

0

Most black lines are duos of [TCP ACKed unseen segment] and [TCP Spurious Retransmission]. The reason for these lines to be marked black is that Wireshark sees the ACK to the TCP segment first and then the next packet in the capture file is the actual TCP segment that was ACKed.

In short: the frames are out-of-order in the capture file.

What was your capture setup? Did you use a span-port? A TAP? Or were you capturing on one of the endpoints?

As for the DUP-ACKs, there are about 40 lost packets that trigger retransmissions, but each lost packet generates quite a few DUP-ACKs, as there are already more packets on the wire before the retransmission is sent. Each of these packets will generate a DUP-ACK.

SYN-bit's avatar
18.5k
SYN-bit
answered 2022-08-18 14:02:29 +0000
edit flag offensive 0 remove flag delete link
more

Comments

thanks for the replay.

The capture is a Port Mirror on the Switch the Laptop is connected to. In an iperf test I am seeing a lot cleaner pcap. The link to the pcap from the other day is a slightly different test setup but still same place for the packet cap - the SW port mirror.



Laptop(1Gb)---SW(1Gb+Wireshark)---RT(100Mb)---WanEmulation(6Mb)---RT(100Mb)---FWL(1Gb)---SW(1Gb)---VM+Server(1Gb)



With Iperf, I was seeing 3Mb across the WanEMU and 0.00 throughput on the Laptop. But took the latency off the WanEMU and got the full 6Mb. After setting the bitrate on iperf(TCP) the Bandwidth results showed. I did see to [TCP Window Full] on some ipfer test but as I understanding it thats OK, as Wireshark is just stating the exact window was full as not other black packets.

We were using a ... (more)

dave47's avatar dave47 (2022-08-20 02:17:23 +0000) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer