ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] [TCP segment of a reassembled PDU] question...

Date: Mon, 5 Jan 2009 01:20:56 +0100
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