Perhaps I missed it, but how are these packets captured? Port mirroring/spanning may have different packets than an inline probe or wireshark running on the host machine.
Also if wireshark is running on a Windows host there have been issues with packets containing 802.1q (vlan) data.
Alex Lindberg
Andrea <an.celli@xxxxxxxxxx> wrote:
Hello Jim, here is my first cut of tracefile:
http://www.cloudshark.org/captures/4b8cf621d044
It contains conversation from when I start application, and on row 717 there is first spanning tree .
I hope in your supporta
Thanks
Andrew
Jim Aragon <Jim@xxxxxxxxxxxxxxxxx> ha scritto:
At 10:41 AM 7/14/2012, you 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 to receive another packet from the server
(192.168.1.2) , I think this cannot be normal behaviour.
It would be easier for us to possibly analyze what's going on if you'd
post an actual capture file somewhere (perhaps
www.cloudshark.org) instead of a partial text listing. Try to capture
the start of the conversation so that the TCP three-way handshake is
present in the trace file. If necessary, remove any confidential
information from the trace file. Include the full STP frames.
Jim
