[68] in linux-net channel archive
Re: UDP: bad checksum - Warnings
daemon@ATHENA.MIT.EDU (Matti E. Aarnio [OH1MQK])
Tue Feb 7 16:09:25 1995
From: "Matti E. Aarnio [OH1MQK]" <mea@mea.cc.utu.fi>
To: linux-activists@niksula.hut.fi
Date: Tue, 7 Feb 1995 21:23:19 +0200 (EET)
Cc: linux-net@vger.rutgers.edu
In-Reply-To: <95Feb7.184837eet.55712-1@niksula.hut.fi> from "Linux Activists" at Feb 7, 95 06:48:31 pm
>> I noticed in my /var/adm/messages logfile a lot of UDP: bad checksum warnings.
>> Here are some of them:
>>
>> Jan 25 22:32:36 lst kernel: UDP: bad checksum. From C65FFB0A:53 to 83BC2CFF:53 ulen 51
>> Jan 25 22:32:36 lst kernel: UDP: bad checksum. From 83BC0302:2049 to 83BC2C6F:667 ulen 1132
>> Jan 26 11:00:17 lst kernel: UDP: bad checksum. From 814F0109:53 to 83BC2CFF:53 ulen 45
>
> There are some TCP/IP stacks which don't calculate the UDP checksum properly
> in the first place. Hence some other software doesn't check them. Thus the
> problem may actually be with whatever is at the other end (just a
> possibility).
>
> Alex
The message may be annoying, but I do think it is usefull; when
you know what to do with it -- aside of ignoring it, that is.
As I am the one, who talked Linus around to let UDP to log bad
received checksums, perhaps I should "defend" the theory a bit.
Originally the message was "UDP: bad checksum", and THAT was too
little for me :) ("What it was? ProtocolCop to be sent out!")
I have had my share of (bad) experiences with cases of bad UDP
checksums being accepted as valid data; among them, results were
scrambled DNS entries, and one proprietary protocol having problems..
.. therefore I like it very much, that Linux does not even have
an option to DISABLE the UDP checksums, like BSD-unixes (4.2, 4.3)
had, and systems derived from them (SunOS 4.x ...)
.. and therefore I do like to be able to determine, what the bad
packet was, and where it was coming from, because it may indicate
possibly serious trouble in the network.
Unfortunately my most common case of captured bad UDP checksums
is BOOTP request, which carries its important identity elsewere
in the datagram...
There was recently a fix for UDP checksums, so perhaps the problem
was not on the network after all ? Now I run 1.1.89, and the
frequency has definitely dropped. (Only one case in last 35 hours.)
1 UDP: bad checksum. From 82E80101:123 to 82E8FFFF:123 ulen 56
1 UDP: bad checksum. From 82E80101:513 to 82E8FFFF:513 ulen 1028
1 UDP: bad checksum. From 00000000:67 to FFFFFFFF:67 ulen 308
115 UDP: bad checksum. From 00000000:68 to FFFFFFFF:67 ulen 308
But there are also clear cases of true bogons, I guess I have
to increase loggings so that I can catch those PCs(?) with faulty
software...
> ----------------------------+-------------+-----------------------------
> Alex Bligh : ,-----. :
> Computer Concepts Ltd. : : : alex@cconcepts.co.uk
/Matti Aarnio <mea@utu.fi>
<mea@nic.funet.fi> Postmaster
