Hello Andrew,
On 7/15/12 5:24 AM, "Andrea" <an.celli@xxxxxxxxxx> wrote:
>Thanks all guys for good answers, so I see that STP is not the problem
>in my case and these delay second due to host processing time (client).
>
>But I don't know why this application take too many time to start (about
>25 seconds), please take a look on this second trace (another cusotmer
>LAN with the same app starts):
>http://www.cloudshark.org/captures/e95c1068086f
>
>from packets 680 to 701 has been nearly 2 seconds meanwhile there are
>many multicast packets, can this a contribute to cause this delay?
>
In your case2.pcapng trace file you again have a device sending
stp packets every two seconds (this time the device with mac
address 00:14:7c:2c:08:38). And like in your original trace these
stp packets have nothing to do with your delays.
This trace appears to have been taken on host with mac address
2c:27:d7:1f:a6:85 (ipv4 address 192.168.70.40). We can make this
assumption because all of the ip header checksum errors are
associated with this one host (192.168.70.40), this is consistent
with header checksum offloading.
Disregarding the non-tcp packets you noted a delay between packets
680 and 701. But these two packets belong to two different TCP
conversations.
The delay that is perhaps more important is the one between frame
680 and frame 705 of 1.678714 seconds which are two packets from
the same conversation. And similar to the first trace you posted
you will see that frame 680 is a TCP ACK sent by 192.168.70.40
(after a delay of about 0.2 seconds from the previous packet) and
that frame 705, the next frame in that conversation is also and
egress packet from the 192.168.70.40. This again looks like client
side processing delay.
Frame 701 is a part of a different TCP conversation. The previous
frame from this conversation was 445 which was a TCP ack followed
2.096514 seconds later by frame 701, an http POST.
The biggest tcp conversation delay I saw was 4.347130 seconds
between frame 67 and 98 which again follows the same pattern in
that both packets are egress packets from 192.168.70.40 on one
particular conversation.
>And in the same case (and same trace file but because is too big I've
>split the file), I've seen many TDS protocol (SQL transaction) with
>malformed packets:
>http://www.cloudshark.org/captures/2c90ee59e7fa
>
>take a look at packets 80 , 156, 213, 245, 251, 275, 297, 307 , etc..
>
>what do you think of this?
>
>Andrew
Cloudshark is flagging these packest as "[Malformed Packet: TDS]".
But my copy of Wireshark reports the same "malformed" packets as:
> "[Expert Info (Warn/Reassemble): Unreassembled Packet (Exception
>occurred)]"
My Wireshark is a development version 1.9.0-SVN-43660 (SVN Rev 43660 from
/trunk) which I recently downloaded from Wireshark's development build
folder.
These same messages exist in your other trace files for some of the TDS
packets and also for some of the SMB packets. I suspect this is simply
a parsing/dissecting issue due to unexpected/unknown TDS and SMB dialects
and/or extensions. I doubt Wireshark's inability to fully parse these
packets is indicating that you have found the root cause of your delay
issues.
Unfortunately I haven't seen any smoking gun in your traces that indicates
you have a network issue that is causing your delays. Virtually all the
client requests are answered by the server virtually immediately. But
others with more TDS and/or SMB experience may have a different opinion.
Best regards,
Jim Y.