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? Its also at https://www.cloudshark.org/captures/a198e1dad32c asked 16 Jan ‘13, 19:12  Willmeister |
2 Answers:
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: 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 answered 17 Jan '13, 00:34  SYN-bit ♦♦ 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:
The second reason is often observed when Windows Vista / Win 7 pulls data from a Server 2008. Good hunting! answered 17 Jan '13, 03:55  packethunter 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:
(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 |
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?
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.