Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2369
  • Last Modified:

Bad checksum question

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)!) 172.25.22.107.4828 > 172.16.1.32.8080: 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)
172.16.1.32.8080 > 172.25.22.107.4828: 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)!) 172.25.22.107.4828 > 172.16.1.32.8080: . [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)!) 172.25.22.107.4828 > 172.16.1.32.8080: P [bad tcp cksum 726f (->bb6a)!] 1:673(672) ack 1 win 64512
0
dissolved
Asked:
dissolved
1 Solution
 
FatherErvinCommented:
Disable Qos????
0
 
ChireruCommented:
The output you posted says:
172.25.22.107  sent something to  172.16.1.32
172.16.1.32  acknowledged it
172.25.22.107 sent something corrupted to 172.16.1.32, which failed tcp header checksum, was marked bad and dropped.
172.25.22.107 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.
0
 
PennGwynCommented:
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....)

0
Microsoft Certification Exam 74-409

VeeamĀ® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

 
ChireruCommented:
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.
0
 
dissolvedAuthor Commented:
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?
Thanks
0
 
ChireruCommented:
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.
0
 
dissolvedAuthor Commented:
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
0
 
ChireruCommented:
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).
0
 
dissolvedAuthor Commented:
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?
0
 
ChireruCommented:
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).
0
 
dissolvedAuthor Commented:
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?
0
 
ChireruCommented:
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.
0
 
dissolvedAuthor Commented:
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.
0
 
ChireruCommented:
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.  

0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now