Wireshark-users: Re: [Wireshark-users] Retransmission because of no ACK from user
Alan,
Your problem is real enough - I was questioning vincent paul.
Regards, Martin
MartinVisser99@xxxxxxxxx
On 18 January 2011 00:24, Alan Tu <8libra@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx
>>
>>
>>
>> On 17 January 2011 18:12, vincent paul <amoteluro@xxxxxxxxx> 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@xxxxxxxxx>
>>> To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx>
>>> 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@xxxxxxxxxxxxx>
>>> Archives: http://www.wireshark.org/lists/wireshark-users
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>>
>>> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>
>>>
>>> ___________________________________________________________________________
>>> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
>>> Archives: http://www.wireshark.org/lists/wireshark-users
>>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>>
>>> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>>>
>> ___________________________________________________________________________
>> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
>> Archives: http://www.wireshark.org/lists/wireshark-users
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>>
>> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
> ___________________________________________________________________________
> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>
