Bug 111681 - Invalid ICMP type 11 messages echo'd to console
Summary: Invalid ICMP type 11 messages echo'd to console
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: David Miller
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-08 18:24 UTC by Ken Crandall
Modified: 2007-11-30 22:06 UTC (History)
4 users (show)

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

Attachments (Terms of Use)
Fix for ICMP kernel log message (1023 bytes, patch)
2004-01-13 23:54 UTC, David Miller
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2004:188 normal SHIPPED_LIVE Important: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 2 2004-05-11 04:00:00 UTC

Description Ken Crandall 2003-12-08 18:24:42 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4)
Gecko/20030922 Galeon/1.3.10

Description of problem:

The following (IP address of customer box removed) gets echo'd to the
console periodically:

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

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

How reproducible:

Steps to Reproduce:
Just ifup eth0 and wait...

(Customer notices that activating ypbind seems to accelerate messages)

Additional info:

Comment 1 Arjan van de Ven 2003-12-08 18:32:10 UTC
what kind of firewall rules are active?
what kind of loglevel is set ? 

Comment 2 Gerry Dalton 2004-01-07 20:44:50 UTC
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 to  It is becoming very annoying 
when trying to work

Comment 3 Leif Thuresson 2004-01-08 16:16:40 UTC
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.

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


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 ]


On 2.6.0-test4 I see this warning in my logs: sent an invalid ICMP type 11, code 0 error to a
broadcast: 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.


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,

Comment 4 David Miller 2004-01-13 23:54:17 UTC
Created attachment 96958 [details]
Fix for ICMP kernel log message

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

Comment 5 Werner Maes 2004-01-20 13:48:34 UTC
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.

Comment 6 Werner Maes 2004-01-21 13:38:53 UTC
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

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.

Comment 7 Leif Thuresson 2004-01-21 13:50:40 UTC
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

Comment 8 James Sjogren 2004-02-05 13:51:30 UTC
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.

Comment 9 Ernie Petrides 2004-02-06 06:08:00 UTC
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.

Comment 10 Tom Haynes 2004-03-28 20:15:52 UTC
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"

Comment 11 John Flanagan 2004-05-12 01:07:53 UTC
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.


Comment 12 Kosting 2005-07-07 08:56:50 UTC
(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

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