Wireshark mailing list archives
Re: Retransmission because of no ACK from user
From: vincent paul <amoteluro () yahoo com>
Date: Wed, 19 Jan 2011 15:24:33 -0800 (PST)
Hi Martin, "Retransmission because of no ACK from the user" is what I observed from a customer's file. regards, ________________________________ From: Martin Visser <martinvisser99 () gmail com> To: Community support list for Wireshark <wireshark-users () wireshark org> Sent: Tue, January 18, 2011 3:52:54 AM Subject: Re: [Wireshark-users] Retransmission because of no ACK from user Alan, Your problem is real enough - I was questioning vincent paul. Regards, Martin MartinVisser99 () gmail com On 18 January 2011 00:24, Alan Tu <8libra () gmail com> wrote:
Martin, There is a problem because once one of my clients (phone) sends an HTTP request, and the response starts flowing, no more ACKs from the client reaches the server. This causes failed web page retrieval. This is client/server specific, and is systematic. I can infer that the ACKs from the client are not making it by the TCP reply timestamp from the server never incrementing after the HTTP GET request. I compared line by line the difference between a failed connection from the phone client and a successful connection from the Windows client. I used netcat to duplicate the phone's HTTP request to rule out a problem at the HTTP layer. I noticed that my phone used the TCP timestamp option and checked this on Windows 7 by running netsh int tcp show global TCP timestamps was disabled, so I enabled it: netsh int tcp set global timestamps=enabled I then reran netcat. The netcat made the identical HTTP request, and now Windows uses timestamps. Unlike with the phone, the ACKs were making it to the server (again, I can infer by examining the TCP reply timestamps from the server). I replicated the phone's failed request on my PC as close as I could with the available tools, and the request succeeded. I then compared the failed connection with the successful replicated connection looking for differences, and I found very little differences. One of the differences was that my phone advertised a window scale factor of 0 (2 power 0 = 1 or no shift, but supports scaling in the other direction.) Maybe somehow, the server TCP stack drops TCP packets of segment size 0 (follow-on ACKs) if the window scale is set to 0. I'm grasping at straws. So in summary, the initial HTTP GET request is received by the server, but no ACKs after that are received, causing the server to time out. This is a systematic issue and not random packet loss. I simply am at a loss at this packet discrimination. Alan On 1/17/11, Martin Visser <martinvisser99 () gmail com> wrote:Is there an actual problem to be solved or are you just curious. Retransmissions aren't all that unusual. If there is fluctuation in round-trip-time as measured by TCP, then the TCP retransmission timer might expire more often than you would like. Hence you will get retransmissions. Regards, Martin MartinVisser99 () gmail com On 17 January 2011 18:12, vincent paul <amoteluro () yahoo com> wrote:Thank you for the response. user did receive the packet twice. This is the reason why wireshark label the second packet as retransmission. regards, ________________________________ From: Andrew Hood <ajhood () fl net au> To: Community support list for Wireshark <wireshark-users () wireshark org> Sent: Sun, January 16, 2011 3:27:24 AM Subject: Re: [Wireshark-users] Retransmission because of no ACK from user vincent paul wrote:Hi All, I am looking at one trace with retransmissions from server because user's side did not send ACK for packets it received from server. Is there any reason why user's side does not send out ACK.Do you know the client did receive the data or is that an assumption? What is between the server and the client? Can you sniff the traffic at intermediate points? Do you see the session setup packets (SYN, SYN+ACK, ACK) and then when the data starts, the ACKs stop? This could be the classic "firewall dropping ICMP frag required packets" behaviour. Can you reduce the MTU at the server? In Windows you have to reduce it with a registry setting and that affects all interfaces and requires a reboot. Unixish systems let you set the MTU on route commands. If there is any ADSL involved, 1492 is a likely value for the MTU. 1460 is the next most likely value. Andrew -- There's no point in being grown up if you can't be childish sometimes. -- Dr. Who ___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- Help decrypting with known WEP key Marty Gramlick (Jan 13)
- Retransmission because of no ACK from user vincent paul (Jan 15)
- Re: Retransmission because of no ACK from user Sake Blok (Jan 16)
- Re: Retransmission because of no ACK from user Andrew Hood (Jan 16)
- Re: Retransmission because of no ACK from user vincent paul (Jan 16)
- Re: Retransmission because of no ACK from user Martin Visser (Jan 17)
- Re: Retransmission because of no ACK from user Alan Tu (Jan 17)
- Re: Retransmission because of no ACK from user Martin Visser (Jan 18)
- Re: Retransmission because of no ACK from user vincent paul (Jan 19)
- Retransmission because of no ACK from user vincent paul (Jan 15)