I think that as part of my troubleshooting, I should've use traceroute,
that would for sure identify whether the problem was in some router
along the way or the server itself... no I didn't use either ping or
traceroute as part of my troubleshooting and the reason why, was b/c I
immediately browse to other sites and they all worked just fine....
thanks all for the comments
-JV
blog: www.pctechtips.org
j.snelders@xxxxxxxxxx wrote:
> On Sun, 4 Jan 2009 22:03:02 +0100 Sake Blok wrote
>
>> On Sun, Jan 04, 2009 at 09:15:19PM +0100, Gergely Bacsk? wrote:
>>
>>> I found the following, hope that helps:
>>> (I used this filter because I assume this is between host and the
>>> appropriate server: ip.addr==10.200.50.111 && ip.addr==208.109.181.58
>>>
> )
>
>>> I think the server is not slow, because in packet 7-8-9-10 (use my
>>> filter) the IP IDs are 13908 13909 13910 13911 so I think that means
>>> that the server in not busy, because it is sending you continuous IP
>>> IDs. If the server would have been busy (eg serving other clients at the
>>>
>>> same time) IP IDs would have been like 13908-14258-15689-16898...
>>>
>> Well, from RFC 791:
>>
>> "The identification field is used to distinguish the fragments of one
>> datagram from those of another. The originating protocol module of
>> an internet datagram sets the identification field to a value that
>> must be unique for that source-destination pair and protocol for the
>> time the datagram will be active in the internet system."
>>
>> Since the first connection to the server will be a single one, the ip
>> identification only needs to be unique within the
>> 10.200.50.111/208.109.181.58/6(tcp) conversation. Which can be
>> accomplished by increasing the id by 1 for every new ip packet. So this
>> tells you nothing about how busy the server is serving data to other
>> clients.
>>
>>
>>> TCP receive window size is also OK.
>>> Maybe need some Apache fine-tuning ???
>>>
>> Since the request (frame 5&6) are ACK'd after about 90ms (frame 7&8),
>> there is not much network delay. So, it seems the delay is caused on the
>> server.
>>
>> What does strike me as odd, is the fact that the server first anounces a
>> tcp window size of 0, but the after the 3way handshake, it announces a
>> new window size of 5840. But that does not seem to be related to the
>> slowness of the first response, cause the following requests get a 304
>> response back quickly, while showing the same window size oddness.
>>
>
> There is a referer in packet 6:
> Referer: http://pctechtips.org/building-a-wireless-bridge-with-dd-wrt/\r\n
> I suppose Jorge L. Vazquez started the capture just before jumping back home:
> Request URI: /
> Could this explain the window sizes?
>
>
>> I would take a look on the server on why it is server the answer so
>> slowly.
>>
>
> Follow TCP Stream
> (ip.addr eq 10.200.50.111 and ip.addr eq 208.109.181.58) and (tcp.port eq
> 1651 and tcp.port eq 80)
> <snip>
> HTTP/1.1 200 OK
> Date: Sat, 03 Jan 2009 18:49:32 GMT
> Server: Apache
> X-Pingback: http://pctechtips.org/xmlrpc.php
> X-Powered-By: PHP/4.3.11
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Transfer-Encoding: chunked
> Content-Type: text/html; charset=UTF-8
> <snip>
>
> Does Pingback causes the delay?
>
> Thanks
> Joan
>
>
>> HTH,
>> Cheers,
>> Sake
>>
>
>
>
>
>
> ___________________________________________________________________________
> 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
>
>
