From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040924 Firefox/0.10 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): iputils-20020927-13 How reproducible: Always 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!
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"
Created attachment 105577 [details] Ping from fresh fc2 installation with wrong checksum
Created attachment 105579 [details] Ping from fresh fc2 installation with wrong checksum
Created attachment 105580 [details] hping which is working
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 lan-port). 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 10.2.50.121 I get the answer back.
Seems to me like duplicate of this bug #136618 . Which NIC are you using?
or recently bug #129823
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 checksum?
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 http://www.ethereal.com/lists/ethereal-users/200210/msg00065.html
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 ping-utility. 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: http://www.globotech.ch/html/infokanal.html Please close this bug because it's not a bug from linux. Thank you for your great support in this case!