Bad checksum question

Disable Qos????

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.

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....)

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.

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

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.

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

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).

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?

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).

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?

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.

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.