Question : 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

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

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

Answer : Bad checksum question

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.