This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

I get hundreds of these when i copy from my windows 2003 server at one site to a windows 2008 r2 server at another. Any idea on what's going on or how to troubleshoot it?

10193   0.000000000 192.168.20.30   192.168.183.10  TCP 1514    [TCP Fast Retransmission] [TCP segment of a reassembled PDU]

10203   0.003003000 192.168.20.30   192.168.183.10  TCP 1514    [TCP Retransmission] [TCP segment of a reassembled PDU]

Its also at https://www.cloudshark.org/captures/a198e1dad32c

asked 16 Jan '13, 19:12

Willmeister's gravatar image

Willmeister
6446
accept rate: 0%

You say you get hundreds of retransmissions, but when I load your capture file, I only see 11 retransmissions, and they do not include the two packets that you show above, numbers 10193 and 10203. What version of Wireshark are you using?

(16 Jan '13, 22:02) Jim Aragon

Oh i should have explained that. That capture above (packet numbers 10203 10193) was the 10 second capture i had originally. It was 50 megs. I couldn't upload it. I had to quickly grab a smaller one to upload. Since the file copy i was doing originally stopped i had to do the whole process over...i just didn't update the above.

(17 Jan '13, 03:48) Willmeister

Assuming you refer to the "[TCP segment of a reassembled PDU]" messages when saying "I get hundreds of these", these are perfectly normal messages. Wireshark re-assembles higher layer protocol PDU's. This means multiple packets that belong together will be shown as one appliaction message. Have a look at frame 1849, it says:

24 Reassembled TCP Segments (32831 bytes): #1815(304), #1818(1460), #1819(1460), #1820(1460), #1822(1460), #1823(1460), #1825(1460), #1826(1460), #1827(1460), #1829(1460), #1830(1460), #1832(1460), #1833(1460), #1835(1460), #1836(1460), etc.

This means the SMB PDU "Read AndX Response, FID: 0x4017, 32768 bytes" was split over 24 packets (which is logical as the payload part of that PDU alone is 32768).

More info on http://wiki.wireshark.org/TCP_Reassembly

permanent link

answered 17 Jan '13, 00:34

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

It's not the reassembly's i'm concerned with. It's the fact they are Retransmissions. Unfortunatley i'm limited to a 10meg upload on that site so you don't see the problem as I do.

When i copy between the 192.168.183.10 and 192.168.20.30 server it may take about an hour to copy several hundred MB. When i copy the same files from 192.168.183.10 to 192.168.183.11 it's seconds....and no Retransmissions. Trying to track down what may be happening on 192.168.20.0/24's network. Or server NIC. But I get the same issue with 192.168.20.10 as well.

(17 Jan '13, 04:02) Willmeister

Assuming that you refer to "[TCP Retransmission]" that usually indicates trouble - or at least potential trouble.

Most file copy programs rely on TCP to facilitate the data transfer. The receiver acknowledges received data. If a packet is lost for any reason it is retransmitted by the sender.

Wireshark usually does a good job in detecting the retransmission and marks those packets.

An occasional retransmission is not a big matter. However, an excessive number of retransmissions (like "hundreds") will significantly increase the time for the file transfer and annoy the user.

Packets get lost for any number of reasons. Here are a few likely candidates for large number of retransmissions:

  • Full Duplex / Half Duplex mismatch (check the configuration of the network card and switch interfaces)
  • The server transmits data with a high speed (say 1 GBit) and the receiver is connected with a lower speed (say 100 MBit). Drops occur if the receiver is signalling a large TCP window size, found in the TCP header.
  • One of your routers is configured with a quality of service rule that enforces a certain the bandwidth
  • A broken cable offers very poor signal quality
  • A wireless network is busy or suffers from interference

The second reason is often observed when Windows Vista / Win 7 pulls data from a Server 2008.

Good hunting!

permanent link

answered 17 Jan '13, 03:55

packethunter's gravatar image

packethunter
2.1k71548
accept rate: 8%

I'm leaning here: The server transmits data with a high speed (say 1 GBit) and the receiver is connected with a lower speed (say 100 MBit). Drops occur if the receiver is signalling a large TCP window size, found in the TCP header.

I'm going to have them change one server and lock it down to 100 full as my next step.

Thank you.

(17 Jan '13, 04:06) Willmeister
2

Please be careful with changes to your life network.

The Gigabit link allows the server to serve multiple clients simultaneously. Forcing the system to 100 MBit could hurt you more than you gain.

For your "hundreds" of retransmissions, an FDX / HDX mismatch somewhere between transmitter and receiver is a likely reason.

Another mundane explanation is, that another connection is using bandwidth at the choke point during the times of drops.

Please include the following steps in your analysis process:

  • Check error counters of all switch / router ports involved
  • Check drop counters of all switch / router ports involved
(17 Jan '13, 05:08) packethunter

I don't understand the second reason. What triggers the retransmit? How can I know if this reason is applicable to my capture?

(07 Apr '14, 20:06) xkgt
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×104

question asked: 16 Jan '13, 19:12

question was seen: 60,339 times

last updated: 07 Apr '14, 20:06

p​o​w​e​r​e​d by O​S​Q​A