This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Network Analysis

0

I am trying to do some network analysis to find out why one of my switches is so slow. As a test, I created a capture during which I copied a file from the host system to another system on the network. In the capture, I could see at least 20 other systems that were communicating with my host. I tried to determine what some of them were, and I could see that several were related to Windows Media Player and schemas.xmlsoap.org. Many of these packets are highlighted in black with red text, which I believe means they were dropped.

Any suggestions on weather or not this is normal? What other steps could I take to further analyze what's going on. Thanks!

asked 15 Sep '11, 07:40

IsPurchase's gravatar image

IsPurchase
1111
accept rate: 0%

edited 15 Sep '11, 19:38

helloworld's gravatar image

helloworld
3.1k42041


One Answer:

2

The first step is to determine why the packet is colored the way it is. In the Packet Details pane, expand the frame section. If the packet matches a coloring rule, you will see an entry for Coloring Rule Name, and Coloring Rule String. The Coloring Rule String will show what display filter condition the packet matched.

The default Wireshark installation has a coloring rule named "Bad TCP" which uses red text on a black background. This coloring rule matches the condition "tcp.analysis.flags". This is probably what you're seeing. By itself, this information isn't tremendously helpful, because tcp.analysis.flags matches several different TCP conditions.

To see exactly what triggered the tcp.analysis.flags, expand the Transmission Control Protocol section of the Packet Details pane. Under that, expand "SEQ/ACK analysis" then expand "TCP Analysis Flags." This will list exactly what caused the packet to match the tcp.analysis.flags filter. After you've examined a few of these packets, you'll notice that an abbreviated version of this information is shown in brackets in the Info column of the Packet List pane, so you don't really have to expand anything in the Packet Details pane. For example, "[TCP Window Update]".

answered 15 Sep '11, 09:05

Jim%20Aragon's gravatar image

Jim Aragon
7.2k733118
accept rate: 24%

Thank you for your reply. Here is what I found. The 'Coloring Rule Name' is 'Checksum Error.' Under the 'SEQ/ACK' header I don't see any information. Under the Internet Protocol Version 4 head there is one line that is highlighted in red that reads. "Header checksum: 0x0000 {incorrect, should be 0x08fe (maybe caused by "IP Checksum offload"?)]"

(15 Sep '11, 10:51) IsPurchase
1

Checksum Offload means the checksum is calculated by the NIC driver instead of the OS. Therefore, an outgoing packet doesn't have the correct checksum when Wireshark sees it, but does have the correct checksum when the packet is transmitted on the wire. In this case, the checksum error will be seen only on outgoing packets and the error is cosmetic.

One way to make the error go away is to turn off checksum offload in the NIC properties. Remember that you can have IP checksum offload, TCP checksum offload, or UDP checksum offload.

Another way is to disable the Checksum Errors coloring rule.

(15 Sep '11, 12:39) Jim Aragon
1

...and yet another way is to disable IP checksum validation. Menu: Edit > Preferences > Protocols > IPv4 > Validate the IPv4 checksum if possible (uncheck this box)

(15 Sep '11, 19:33) helloworld