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
