what kind of firewall rules are active?
what kind of loglevel is set ? 

I am seeing this same activity on 2.4.21-4.0.2.EL.  I do not have the 
iptables enabled.  I do not know how to check the log level.  A RH9.0 
box sitting next to it does not exhibit the same symptons.  The 
message appears to always go to the Broadcast Address in our case 
from 10.96.126.200 to 10.96.126.255.  It is becoming very annoying 
when trying to work

I've also seen this on 2.4.21-4.EL. The problem is that you have
some device on your network that incorrectly sends a ICMP time
exceeded response to broadcasts where ttl == 0. The linux kernel
reports such bogus messages in the system log by default. 
The code that actually does the logging was updated to be more 
verbose sometime between 2.4.19 and 2.4.21 I think, but unfortunately
the update introduced a bug so that the log message incorrectly list
the destination address as the source address of the bogus message ! 
So you cannot find the bad device with the information in the log
message. You have to use a network packet sniffer instead.
To get the correct address of the bad packet the kernel must be fixed 
(see included mail below)
You can also try to find the bad device with send out the packages
It is also possible to turnoff logging of bad ICMP packages in the
linux kernel if you just think the messages are annoying.

Do:
# /sbin/sysctl âw net.ipv4.icmp_ignore_bogus_error_response=1
 
or put it in /etc/sysctl.conf if you want it if permanently.


 /Leif

Mail below is about the bug in kernel version 2.6 but it 
is exactly the same bug in 2.4.21


[Patch] Wrong warning of invalid icmp to broadcast
From: Dennis Jørgensen
Date: Wed Aug 27 2003 - 20:40:58 EST

    * Next message: Jamie Lokier: "Re: Lockless file reading"
    * Previous message: Con Kolivas: "[BENCHMARK] 2.6.0-test4{-mm2}
with contest"
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hello

On 2.6.0-test4 I see this warning in my logs:

192.38.215.157 sent an invalid ICMP type 11, code 0 error to a
broadcast: 192.38.215.255 on eth0

The ip is wrong, since it's the ip of my own machine. The following
patch fixes it (so the ip reported is the same as 2.4.20 reports).

If I should send this somewhere else, please tell me.


Regards

Dennis Jørgensen
I'm not on the list, please CC: me.


--- linux-2.6.0-test4.org/net/ipv4/icmp.c 2003-08-28
01:13:59.000000000 +0200
+++ linux-2.6.0-test4/net/ipv4/icmp.c 2003-08-28 02:12:56.000000000 +0200
@@ -661,7 +661,7 @@
printk(KERN_WARNING "%u.%u.%u.%u sent an invalid ICMP "
"type %u, code %u "
"error to a broadcast: %u.%u.%u.%u on %s\n",
- NIPQUAD(iph->saddr),
+ NIPQUAD(skb->nh.iph->saddr),
icmph->type, icmph->code,
NIPQUAD(iph->daddr),
skb->dev->name);

Created attachment 96958 [details]
Fix for ICMP kernel log message

This should fix it, simply a backport of the 2.6.x fix.

this issue seems to be fixed in kernel-2.4.21-9.EL. i've taken a look
at the source (icmp.c) and the patch has been added. And I can confirm
that I no longer see these ICMP kernel log messages.

seems I jumped to the conclusion too fast. the errors still occur.
apparently this seems to be fixed in the latest kernel (2.4.25-pre6) only

changelog.
David S. Miller:
   o [IPV4]: Print correct source addr in invalid ICMP msgs, from
Dennis Jorgensen

And I would find it hard to believe that redhat has already updated
their rpms. Apparently the kernel maintainers added more stuff to the
file icmp.c than redhat in its latest kernel.

Just to clarify things:
The fact the message actually occur is not a bug in Linux.
It occurs because there is another network device on the same subnet
that sends out an icmp 11 message in response to a broadcast which
is incorrect behavior. The Linux kernel logs occurrences of bad icmp
messages (can be turned off with sysctl as mentioned earlier)
The bug in the linux kernal is that it prints the wrong source address
when it emits such messages

A note about the above ICMP msgs on RHEL 3 AS and AW:

The above ICMP error becomes particularly astute when using a CUPS
server (i.e. cupsd on the server produces errors, but the clients do
not). Additionally, if cups is used in a direct printing mode the
errors stop.

It appears that old HP printers and digital-senders may not be
generating ICMP type 11 packets correctly.

Thanks for the above fix.

David Miller's fix shown in comment #5 has just been committed
to the patch pool for RHEL3 U2.  It will first appear in the
internal (Engineering) build of kernel version 2.4.21-9.5.EL.

The sysctl "fix" to stop the logging and the echo above needs an "s" 
to work correctly.

Should be "net.ipv4.icmp_ignore_bogus_error_responses=1"

An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2004-188.html

(In reply to comment #3)

> Do:
> # /sbin/sysctl âw net.ipv4.icmp_ignore_bogus_error_response=1
>  
> or put it in /etc/sysctl.conf if you want it if permanently.
 In my case this syntax wrong. Correct syntax is:
# /sbin/sysctl âw net.ipv4.icmp_ignore_bogus_error_responses = 1