?
Solved

[TCP CHECKSUM INCORRECT]

Posted on 2007-11-19
6
Medium Priority
?
11,888 Views
Last Modified: 2013-12-23
Is it normal for Wireshark to be reporting about 33% of all network data as [TCP CHECKSUM INCORRECT]? For each 2 "Continuation of HTTP traffic" packets I get, I also get 1 packet marked as [TCP CHECKSUM INCORRECT] (highlighted in black in Wireshark).
0
Comment
Question by:tylermenezes
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
6 Comments
 
LVL 8

Accepted Solution

by:
static-void earned 500 total points
ID: 20324570
Thats obviousally really bad. Is happening to all hosts or just a specific one? The most likely cause is that you have some seriously bad link in your network. Check for bad cabling. You should start by trying to isolate where the prob is. If your using wireless anywhere thats a good place to start.
0
 

Author Comment

by:tylermenezes
ID: 20324582
I'm pretty sure it's the router (it's fine without it), but I wanted to make sure this wasn't normal.
0
 
LVL 8

Expert Comment

by:static-void
ID: 20324611
yeah if 1/3 is checksum failed that means that another 1/3 is failed packets so only 1/3 of packets are correctly transmitted. Thats real bad
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 

Author Comment

by:tylermenezes
ID: 20324627
Thanks for the help. I assigned points to your earlier response, because it clarified my problem and will probably help anyone else more than is necessary in my case.
0
 
LVL 6

Expert Comment

by:CoreyMac
ID: 22639694
I think as a time-tested question this is just likely wrong...

Checksums are rarely wrong, so look at the checksum value in the trace.  If it is TCP and 0000 (zeros) then the problem is probably bogus.

The source of this is usually the fact the TCP checksums-offload are enabled in the NIC driver and so many of the packets (the ones to/from this machine) have their checksums not calculated until the actual NIC gets ready to transmit the frame.  

Wireshark can't tell so it calls it in error.
0
 

Expert Comment

by:JasonMewes
ID: 23203412
It is common for wireshark to display *almost all* packets as having bad CRC because of checksum offloading (as explained by CoreyMac)... however it seems a bit odd that you have a large number of packets displayed as good? Unless they are UDP packets, for which a CRC of 0 is always valid as it specifies that checksums are disabled for the current packet. The IP level checksum cannot be disabled however, but if this is not offloaded you might find yourself in this exact situation.

In any case, what you can do is to disable offloading in your network card settings:

Control Panel -> Device Manager -> Your network card -> Properties -> General -> Change Settings -> Advanced

Go through the list of properties and disable offloading, on my network card I have disabled the following:

IPv4 Checksum Offload
TCP Checksum Offload (IPv4)
TCP Checksum Offload (IPv6)
UDP Checksum Offload (IPv4)
UDP Checksum Offload (IPv6)

This will put more "strain" on your CPU, but can be useful when wiresharkin'...
0

Featured Post

Optimize your web performance

What's in the eBook?
- Full list of reasons for poor performance
- Ultimate measures to speed things up
- Primary web monitoring types
- KPIs you should be monitoring in order to increase your ROI

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Most of the applications these days are on Cloud. Cloud is ubiquitous with many service providers in the market. Since it has many benefits such as cost reduction, software updates, remote access, disaster recovery and much more.
This article will inform Clients about common and important expectations from the freelancers (Experts) who are looking at your Gig.
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…

752 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question