Solved

Bad TCP checksums

Posted on 2004-09-18
3
5,895 Views
Last Modified: 2013-11-29
I've been noticing some of these in my sniffer logs. A few questions

1. Do packets received with bad checksum errors, let the other side know the data got corrupted/changed on the way there? Or does the receiving end simply just drop the packet?

2. What causes bad checksum errors?  Misconfigured hosts?  Faulty hardware?

3.  I've noticed that I was getting tcp checksum errors when a default gateway wasnt specified on my linux box. When I specified one however, I stopped seeing them.  Did specifying a default gateway correct this?


Also, can someone tell me whats going on here?

08:23:16.729062 00:80:c6:fa:e3:49 > 00:b0:d0:c6:57:11, ethertype IPv4 (0x0800), length 70: IP (tos 0x0, ttl  31, id 8573, offset 0, flags [none], length: 56) 192.168.1.1 > 192.168.1.12: icmp 36: redirect 192.168.4.3 to host 192.168.1.50 for IP (tos 0x0, ttl  63, id 0, offset 0, flags [DF], length: 48) 192.168.1.12.5901 > 192.168.4.3.1201: [|tcp]

It's obviously an ICMP redirect message from my cable router (192.168.1.1) destined for my linux box (192.168.1.12).  But what is this packet telling 192.168.1.12?

0
Comment
Question by:dissolved
3 Comments
 
LVL 4

Accepted Solution

by:
bfarmer earned 250 total points
ID: 12093481
Bad checksums are typically caused by cabling issues, hardware problems, and or driver problems.  

I can't see a gateway setting having much to do with this, but who knows.

The ICMP redirect is telling 192.168.1.12 to use 192.168.1.50 as the gateway for 192.168.4.3.
0
 
LVL 4

Assisted Solution

by:complexymetron
complexymetron earned 250 total points
ID: 12093534
1. TCP provides "secured" data transfer. This means it assures, that data is in the right order and transmitted correctly. So bad checksums would be signalled to the sender, so the packet can be retransmitted by the sender. Look for sequence number and TCP.
(BTW: UDP wouldn't inform the sender. UDP works connectionless - if a packet is wrong it will be dropped)

2. A number of reasons could lead to malformed IP packets. Starts from bad driver on the sender system over faulty hardware (broken cables, etc.) or electromagnetic interference to misconfigured Ethernet frame setting (there are different ones, look for "Ethernet SNAP", "Ethernet 802.2", "Ethernet 802.3", etc. - both stations have to use the same or communication won't work)

3. Normally not. TCP routing works on layer 3 of the OSI networking model, while TCP works on layer 4. Setting a gateway is just setting routing information (e.g. what to do with packets not destined for the local net) - it shouldn't affect reliability of transmission (if connection can be established at all).


Your ethernet trace means:

> 08:23:16.729062 00:80:c6:fa:e3:49 > 00:b0:d0:c6:57:11, ethertype IPv4 (0x0800), length 70: IP (tos 0x0, ttl  31, id 8573, offset 0, flags [none], length: 56) 192.168.1.1 > 192.168.1.12:

= Ethernet frame from MAC1 to MAC2 containing an IP packet from IP1 to IP2

> icmp 36: redirect 192.168.4.3 to host 192.168.1.50

= cleary an ICMP redirect message which informs the host (sender of the original packet) that the gateway found a better route for the packet via the local network and wants to let the host know about that. In this case: "Hey Dude, if you want to reach 192.168.4.3 try 192.168.1.50 as gateway"

> for IP (tos 0x0, ttl  63, id 0, offset 0, flags [DF], length: 48) 192.168.1.12.5901 > 192.168.4.3.1201: [|tcp]

That seems to be a transcript from the original packet the gateway received (this data is included for the host to find the original transmission). The original packet seemed to go from 192.168.1.12 port 5901 to 192.168.4.3 port 1201 using tcp.

For more indepth information, look for RFC 792 (http://www.faqs.org/rfcs/rfc792.html) under "Redirect Message". If you think this behaviour as to be not what you want the gateway to do, then I'd recommend to check the gateway configuration again.
0
 

Author Comment

by:dissolved
ID: 12093560
you guys rock
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

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

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…
PRTG Network Monitor lets you monitor your bandwidth usage, so you know who is using up your bandwidth, and what they're using it for.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

713 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