Hi there, It has been a while that I'm experiencing some problems on my network, as I'm not the network admin and I've got from them the info that everything is OK on the network side I'll need your help to investigate what's going on. I've started the capture and most of the packets had the Checksum error, I've deactivated this filter as per some other post recommendation to see what is left and I can see a couple of packets, when i go to detail window expand the Internet Protocal and the Header, it shows a red highlight on the Header and then on Bad:True, also says Header checksum: 0x0000 [incorrect, should be 0x822f], this 0x822f is replaced by many other numbers for the other packets. Can you help me on this troubleshoot? I can post the capture if necessary. Regards, WRIBEIRO This question is marked "community wiki". asked 13 Aug '12, 04:09  WRIBEIRO |
2 Answers:
Please check if the packets with checksum errors are packets your machine is sending out to the network. If they are, and none of the incoming packets have errors, you can ignore these CRC error messages - they're a result of you capturing your own traffic locally with network card optimizations enabled. Especially the 0x0000 is a typical value for a placeholder when the NIC does the checksum calculation later (after Wireshark captured the packet already). answered 13 Aug '12, 04:22  Jasper ♦♦ |
As Jasper says, the errors are often caused by the network driver calculating the checksum after Wireshark has captured it. You can turn off the display of these errant errors by: For IP checksums right click on the IP part of the frame in the packet details pane (the tree) and go into Protocol Preferences and uncheck "Validate the IPv4 checksum if possible". You may also want to check "Support packet-capture from IP TSO-enabled hardware". For TCP checksums, right click on the TCP part of the frame, and again in Protocol Preferences uncheck "Validate the TCP checksum if possible". answered 13 Aug '12, 04:31  grahamb ♦ Hi Grahamb, Thanks for the info, useful indeed. After your trick the black and red just went off. I've posted another problem, I meant the second phase of this problem above, on Jasper block, any clue on that? Thanks (13 Aug '12, 06:08) WRIBEIRO You should really open another question for that (after searching for a similar one first) rather than trying to change this question to your next problem. (13 Aug '12, 06:42) grahamb ♦ |
There you go, when I sort if from my machine the error comes up, when i sort from my "destination" it goes away. Less one problem. Now i need to find out why, it's so slow. I have a bunch of TPKT - Continuation coming from my server. And also a lot of TCP segment of a reassembled PDU, any clue on that?
"Segment of a reassembled PDU" is not an error, it is a message that Wireshark considers the packet being a part of a larger payload. You can disable the packet reassembly in the TCP protocol preferences by unchecking "Allow subdisector to reassemble TCP streams".
Continuation messages are a similar thing - Wireshark tells you that the packet contains more parts of a payload.
If you try to figure out why communication is slow you should check delta times between requests and answers, the throughput achieved (see Statistics/Conversations/TCP) and filter for problems using tcp.analysis.flags