Bug 136580 - icmp checksum in ping utility is wrong!
Summary: icmp checksum in ping utility is wrong!
Alias: None
Product: Fedora
Classification: Fedora
Component: iputils   
(Show other bugs)
Version: 2
Hardware: i686 Linux
Target Milestone: ---
Assignee: Radek Vokal
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-20 23:28 UTC by Peter Baumann
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-12 09:26:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Ping from fresh fc2 installation with wrong checksum (1.25 KB, text/plain)
2004-10-21 08:39 UTC, Peter Baumann
no flags Details
Ping from fresh fc2 installation with wrong checksum (1.34 KB, application/octet-stream)
2004-10-21 08:39 UTC, Peter Baumann
no flags Details
hping which is working (962 bytes, application/octet-stream)
2004-10-21 08:40 UTC, Peter Baumann
no flags Details

Description Peter Baumann 2004-10-20 23:28:51 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040924

Description of problem:
ping utility calculates wrong checksum!
When I'm doing a tcpdump and decode the pings with ethereal, I see no
"(correct)" behind the icmp-checksum!
When I use hping -1 <host> and do the same trace I will see the
"(correct)" behind the checksum!
I have now a equipment which is not doing a echo-reply to my pings!
When I use as example a win32, BSD or hping everything works!

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. ping <host>
2. check dump with ethereal
3. there's no "(correct)" behind checksum (ICMP)

Actual Results:  I have a equipment which is not answering my pings.

Expected Results:  echo-reply from the host

Additional info:

Tested with various operating systems and did always a trace.
Only with the fc2 ping utility I see a wrong icmp-checksum!

Comment 1 Radek Vokal 2004-10-21 07:52:35 UTC
Hi, I've tested this issue on clear FC2 installation and also on my
system which is more close to FC3 and the bug did not appear. Can you
give my some additional info, your kernel version and ethereal version
will be great as it can also be a bug in one of them. 

Tested on ethereal-0.10.6-2, iputils-20020927-18, kernel-2.6.8-1.521.
Icmp sums for echo reply and request are "correct" 

Comment 2 Peter Baumann 2004-10-21 08:39:20 UTC
Created attachment 105577 [details]
Ping from fresh fc2 installation with wrong checksum

Comment 3 Peter Baumann 2004-10-21 08:39:53 UTC
Created attachment 105579 [details]
Ping from fresh fc2 installation with wrong checksum

Comment 4 Peter Baumann 2004-10-21 08:40:39 UTC
Created attachment 105580 [details]
hping which is working

Comment 5 Peter Baumann 2004-10-21 08:41:45 UTC
Hi Radek
Thanks for the fast reply!
I tested it on a very new installation of fc2 with all the patches.
I have kernel-2.6.8-1.521, iputils-20020927-13, ethereal-0.10.4 (win32
and ethereal-0.10.5-0.2.2 (fc2).
I see again in the icmp-field that the checksum is not "correct" but I
get answer from the host on the internet.
I get still no answer from the other equipment we use (vtx coder with
I attached you two traces:
1. "ping.dmp" Trace from a normal ping on the internet with echo reply
and wrong icmp-checksum (not "correct")
2. "ping-scovery.dmp" Trace from a normal ping to our vtx-coder
equipment which is then not answering, same ping utility used.
3. "hping.dmp" Trace from hping. command used: hping -1 I
get the answer back.

Comment 6 Radek Vokal 2004-10-21 09:06:59 UTC
Seems to me like duplicate of this bug #136618 . Which NIC are you using? 

Comment 7 Radek Vokal 2004-10-21 09:11:27 UTC
or recently bug #129823

Comment 8 Peter Baumann 2004-10-21 09:23:06 UTC
In our firewall we use this card:
02:04.0 Ethernet controller: Adaptec ANA620xx/ANA69011A (rev 03)
(This is the starfire kernel module)
I tought first its because of this network-card since I had also a
problem with this card with 2.6.x kernel.
Strange is when I connect my notebook to the same segment and do the
exactly same ping I get no answer back from the vtx-coder equipment.
Do you really think this is a bug of BOTH network cards?
We only use intel nics (Also included in my ibm a20m) and had never a
problem with it.
I think the vtx-coder is not sending an echo-reply back because the
icmp checksum is wrong.

When I check RFC792 (ICMP) There's the following about icmp checksum:

  Header Checksum

The 16 bit one's complement of the one's complement sum of all 16 bit
words in the header. For computing the checksum, the checksum field
should be zero.  This checksum may be replaced in the future.

What does "This checksum may be replaced in the future." mean?

Should the vtx-coder equipment also accept icmp without the right

Comment 9 Radek Vokal 2004-10-25 09:37:44 UTC
The thing is, that you're using zero copy nic. If you have such a nic
(and intel as I find out is zero copy nic), the checksum of packets
you send will only be calculated when they go over the wire - eg. on
the local machine you see wrong checksum but on the remote machine the
checksum should be ok. You can see them if you connect another machine
to the network and sniff around the packets. Can you check this? 

2nd question: Are you using hping for pinging vtx-coder? (the ip
adresses in the attached file are not describing) 

You'll find more in ethereal mail list

Comment 10 Peter Baumann 2004-11-12 09:25:10 UTC
Sorry for the long delay.
I had no time to test this until now, since the other side is far away
from us.
I could now test it again on the other side with an analyzer and could
see that the packets are right calculated.
Yesterday we had a power outage and this device was not coming up
again (ethernet but rf was working).
After some power-cycles ethernet was coming up again.

For me it is clear now that this device is the problem and not the
It seems that the device cannot answer the slightly different pings
from linux as these from win32 ping.

By the way the device is one of them here:

Please close this bug because it's not a bug from linux.

Thank you for your great support in this case!

Note You need to log in before you can comment on or make changes to this bug.