Bad checksum question

Posted on 2004-09-29
Last Modified: 2007-12-19
If I'm getting bad checksums, then why are the packets being sent?
According to the rules, a host that receives a frame with a bad tcp checksum,  will silently drop the packet and not let the sender know. If this is true, why am I seeing these?

07:51:43.433761 IP (tos 0x0, ttl 128, id 33460, offset 0, flags [DF], length: 48, bad cksum
0 (->85f)!) > S [tcp sum ok] 4210689326:4210689326(0) win 64512 <mss 1460,nop,nop,sackOK>

07:51:43.437944 IP (tos 0x0, ttl  61, id 63181, offset 0, flags [none], length: 44) > S [tcp sum ok] 3634838511:3634838511(0) ack
4210689327 win 65535 <mss 1460>

07:51:43.438029 IP (tos 0x0, ttl 128, id 33462, offset 0, flags [DF], length: 40, bad cksum
0 (->865)!) > . [bad tcp cksum 6fcf (->fcf0)!] 1:1(0) ack 1 win 64512

07:51:43.440965 IP (tos 0x0, ttl 128, id 33463, offset 0, flags [DF], length: 712, bad

cksum 0 (->5c4)!) > P [bad tcp cksum 726f (->bb6a)!] 1:673(672) ack 1 win 64512
Question by:dissolved
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

Expert Comment

ID: 12178914
Disable Qos????

Expert Comment

ID: 12180507
The output you posted says:  sent something to  acknowledged it sent something corrupted to, which failed tcp header checksum, was marked bad and dropped. sent more stuff, which was also corrupted and dropped.

What you are seeing is what you are supposed to.  Those packets will never get to the program they are supposed to get to, but since you are watching in promiscuous mode, the NIC feeds all of the traffic directly to the sniffer, so you can see exactly what's going on.  (How useful would a sniffer be if it didn't show dropped/bad packets?)

What you should be looking into is why you have bad packets..  it's the TCP checksum failing, so you may have a bad cable, or a wacky switch port, or a bad NIC somewhere.
LVL 11

Expert Comment

ID: 12181779
Note that the first packet says "tcp sum ok".  So when it also says "bad cksum", I suspect it's referring to the FCS (Frame Check Sequence).  This is allowed to be left 0000, and devices might not reject packets if this value is wrong.  (It's also wrong in the packets with bad TCP checksums.)

Since the FCS comes at the end of the frame, I suspect that you may be encountering truncated packets or undetected collisions.  (Full duplex means turning off collision detection, so perhaps you have it set somewhere where half duplex is needed....)

Instantly Create Instructional Tutorials

Contextual Guidance at the moment of need helps your employees adopt to new software or processes instantly. Boost knowledge retention and employee engagement step-by-step with one easy solution.


Expert Comment

ID: 12183872
Oh, I didn't see that the first one had an error.

I suspect that the first one, although it had a bad frame checksum, was only wrong by a very few number of bits (1 bit, IIRC)..  if so, then there is enough information to rebuild the broken part, leaving a good TCP frame (it passes TCP checksum, so that part's OK), and would not be dropped.  With very few wrong bits, it can still recover the frame.

Author Comment

ID: 12184610
Thanks guys

The first packet was not dropped. It is a Syn as you can see, and was the only Syn sent in my logs to establish the session.
When you say I am encountering truncated packets, what do you mean?  

If you run full duplex, you dont use CDMA anymore?

Expert Comment

ID: 12185439
A truncated packet can be caused by a few different things, most likely, it's when a "late collision" happens..  a collision that happens after the first 32bytes in a packet.  With hubs and repeaters, they are dumb and will forward any garbage you transmit to them, with switches, unless you have them on store and forward mode, it's likely that they are set to cut-through mode, which only checks the first 32 bytes, then sends it.  So, should the packet collide after 32 bytes, the switch will know no better, and transmit the collided garbage along with it, which will show up as a truncated packet.

On full duplex, it uses 2 wires for send and a seperate 2 wires for recieve.  In that setup, there are two dedicated circuits, between you and the switch.. no-one else can use those lines, so it is not necessary to listen for a collision on your send or recieve wires, as you are the only person transmitting on them, and the switch is the only person transmitting on the recieve pair.

However, there is the occasional network problem where a network card will not negotiate properly, and the switch will think the connection is 100Full, and the NIC thinks it's 100Half, which causes problems.

However, the first packet isn't damaged enough to fall into one of those categories, so I would say that it's a bad cable, or a bad NIC or interference flipping 1 or a few of the bits.

Author Comment

ID: 12185667
I see. So you're saying the FCS of the packet is what was corrupt. The packet did indeed get delivered (even though sniffer output shows it as bad checksum error?).  

I know TCP will not let the other side know if it receives a packet with a bad tcp checksum.  It will not ACK back and hope the sender re-sends the segment. What happens in the event of a bad Frame checksum?  Is it allowed to let the other side know? Does it accept the frame anyway etc?

Also, is CDMA access stil l used when you are in full duplex mode?

Thanks man

Expert Comment

ID: 12186001
In the first one, the frame checksum was bad, but the TCP checksum was OK..  that was replied to with an ACK for the next sequence number, so that frame was not dropped.  

With checksums, depending on how the checksum is calculated, it can correct errors, if only a few bits are wrong, if more than a few are wrong, it can detect the problem, but cannot figure out which ones are wrong.  That is probably what happenned with the first frame, since the TCP checksum passed, and the packet was replied to.

In the third and forth, both the frame and the TCP checksums were wrong, which means the packets were garbage and dropped.

In a TCP session, once it is established, if your computer is downloading, or requesting data from the other side, and you get a garbage packet, it will be discarded, and when you send back the ACK for the rest of it, you will request the packet that was garbage, then once you get that, continue the transfer.  If someone is requesting files off of you are you are uploading, and one of the ACKs is garbage, the downloader will re-ACK after a timeout.  

I'm not 100% sure, but I believe Full Duplex ethernet media still falls under the CDMA/CD standard, but Full Duplex won't detect collisions (because there should be none).

Author Comment

ID: 12216363
so frames with "bad tcp checksums" are always dropped (and later retransmitted)

Where as frames with bad "frame checksums" they can sometimes still be sent and received ok?

Expert Comment

ID: 12217329
First, if you have a situation like this where a computer is spewing bad data onto the network, you should track down the offending computer, and replace it's NIC, patch cable, or switch port, and see which of them stops the bad packets.  You shouldn't let something like that stay on your network.

Both FCS, the frame check sequence, and IP/TCP Checksums are checks that can detect any errors, and is able to recover from them, if there is a small number of errors... so the Frame, IP and TCP can recover from small errors (like a single bit flipped).

Author Comment

ID: 12217824
How can you tell if it recovered from the error or not?
I'm assuming if there is no retransmission of the packet, then it made it through ok?

Expert Comment

ID: 12218224
If it recieved the packet, and corrected the errors, and it's not an ACK, then it will send back an ACK for the next sequence number.  If it's for the same sequence number as the bad packet, then your computer is re-requesting it.
If it was an ACK, it will be resent after a timeout.

Author Comment

ID: 12218662
ok, so just for clarification:

If a host receives a segment with a bad tcp checksum or frame check sum, it can possibly correct it . If it CANNOT correct it , it:

A)  WIll just drop the frame. The RFC states that if a host receives a frame with a checksum error, it drops it. ANd hopes the sender will retransmit, since it wont be receiving an ACK.

Accepted Solution

Chireru earned 500 total points
ID: 12219744
If the RFC says differently from what I say, then always go with what the RFC says.

I see where you are confused now, I was combining two ideas: raw transmission and TCP guaranteed delivery.  If you were using UDP instead of TCP, anything corrupted would simply be dropped and hopes the other side will retransmit.  This is because UDP has no recovery agent.

TCP was made for the sake of guaranteed delivery, so if you have a corrupted frame, that cannot be recovered, it is dropped.  However, TCP will notice that the frame is missing, and the guaranteed delivery will kick in, and the client will ACK the missing frame from the server after the rest of the window is transmitted, then continue on, adjusting the window size and asking for the next window.  If the server recieves a bad ACK, it will be dropped, and the client's TCP guaranteed delivery will kick in and re-ACK after a timeout.  


Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

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

Suggested Solutions

Title # Comments Views Activity
Price for Fiber 13 66
Legal Discovery - Export Keywords to PST 2 55
Certification Follow-up 2 63
Isolated network on ESXi 6.5 8 53
If your business is like most, chances are you still need to maintain a fax infrastructure for your staff. It’s hard to believe that a communication technology that was thriving in the mid-80s could still be an essential part of your team’s modern I…
For many of us, the  holiday season kindles the natural urge to give back to our friends, family members and communities. While it's easy for friends to notice the impact of such deeds, understanding the contributions of businesses and enterprises i…
Viewers will learn how to connect to a wireless network using the network security key. They will also learn how to access the IP address and DNS server for connections that must be done manually. After setting up a router, find the network security…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor ( If you're looking for how to monitor bandwidth using netflow or packet s…

733 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