On 7/14/12 1:41 PM, "Andrea" <an.celli@xxxxxxxxxx> wrote:
>But I don't understand why this pause occurs always on this sequence:
>
>716 8.713191000 192.168.1.12 192.168.1.2 TCP 54 50014 >
>microsoft-ds [ACK] Seq=47596 Ack=55126 Win=63153 Len=0
>717 9.999665000 NexcomIn_1e:63:47 Spanning-tree-(for-bridges)_00
> STP 60 Conf. Root = 32768/0/00:10:f3:1e:63:45 Cost = 0 Port =
>0x8003
>718 10.689862000 192.168.1.12 192.168.1.2 TCP 362 [TCP
>segment of a reassembled PDU]
>719 10.690663000 192.168.1.2 192.168.1.12 HTTP 79
>HTTP/1.1 100 Continue
>
>
>
>More than one second toreceive another packet from the server
>(192.168.1.2) , I think this cannot be normal behaviour.
>
>How
>do I know if is normal orif it is possible optimize it?
And On 7/15/12 12:21 AM, "Jim Aragon" <Jim@xxxxxxxxxxxxxxxxx> wrote:
>At 10:41 AM 7/14/2012, Andrea wrote:
>
>> Hello Jim, here is my first cut of tracefile:
>>
>> http://www.cloudshark.org/captures/4b8cf621d044
> <http://www.cloudshark.org/captures/4b8cf621d044>> It contains
>conversation from when I first start application,
>> and on row 717 there is first spanning tree.
>
>Ok, let's take a look at this data.
>
>There are 8 STP frames in this trace file: Numbers 1, 2, 57, 61, 258,
>717, 776, and 6254.
>
<snip>
Andrea,
I doubt the spanning tree packets have anything to do with your
stall.
If you apply a display filter for just the Spanning tree packets
(stp) you will see that a spanning tree packet is sent every two
seconds (+/-). This is a typical rate that one might see stp
packets sent by a device. (FWIW: All your spanning tree packets
are sourced from the device on your network with mac address
00:10:f3:1e:63:47. If you had multiple devices sending STP
packets your would have a less obvious stp packet rate unless
and until you start filtering by source mac address and stp.)
With the stp display filter in place you can easily see the
metronome like rate of the stp packets if you switch the default
time column to "Seconds since previously displayed packet" or
better yet add a "Delta Time Displayed" column adjacent to the
default "Time (format as specified)" column.
Your trace appears to have been captured on the host with mac address
3c:d9:2b:6e:7e:84 (which also happens to have ipv4 address of
192.168.1.12). We can make this assumption because the TCP packets
that are sourced from 192.168.1.12 have "bad" CRC values while TCP
packets from other hosts have "good" CRC values. In spite of seeing
"bad" CRC values it should be obvious that these packets are part of
a successful and ongoing TCP dialogs with the host at 192.168.1.2.
Having a trace file with "bad" CRC values for TCP packets sourced
from one specific host is consistent with a trace file that was
captured on a machine with checksum offloading enabled. Wireshark's
packet capture mechanism (libpcap/winpcap) is implemented in the
system's OS and will not see the final ip checksum fixups applied
to the outgoing packets by the nic card before the packet is put on
the wire.
Let's assume that the spanning tree packets are not related to
your problem and exclude them from the trace. Apply a display
filter of "!stp".
With the stp packets out of the way you appear to be concerned with
the 1.976671 second pause between frames 716 and 718.
Frame 716 is simply a TCP ACK packet sent by 192.168.1.12 to 192.168.1.2.
Frame 718 is a HTTP POST sent by 192.168.1.12 to 192.168.1.2.
I think that the delay you see between packets 716 and 718 is simply
the host processing time it took host 192.168.1.12 (the machine that
the sniffer was running on) to generate the HTTP POST packet sent
in packet 718.
Hope this helps,
Jim Y.
