Wireshark-users: Re: [Wireshark-users] Spanning tree can slow the network?
From: James Howard Young <jyoung@xxxxxxx>
Date: Mon, 16 Jul 2012 02:39:25 +0000
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.
- Follow-Ups:
- References:
- Prev by Date: Re: [Wireshark-users] WIRESHARK Version 8.1.0 problems in DSCP coding
- Next by Date: [Wireshark-users] noob question: linux vs windows difference
- Previous by thread: Re: [Wireshark-users] Spanning tree can slow the network?
- Next by thread: Re: [Wireshark-users] Spanning tree can slow the network?
- Index(es):
- Get Wireshark
- Download
- Code of Conduct