From: "Taylor, Grant" <gtaylor@riverviewtech.net>
To: netfilter@lists.netfilter.org
Subject: Re: IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error_responses
Date: Sun, 15 May 2005 20:36:18 -0500 [thread overview]
Message-ID: <4287F912.8010208@riverviewtech.net> (raw)
In-Reply-To: <20050507212628.6fd43793@mikejones.ghb.fh-furtwangen.de>
> kernel: XX.XX.XX.XX sent an invalid ICMP type 3, code 1 error to a
> broadcast: 0.0.0.0 on lo
Sorry for the delay in getting back to you. After looking at all the information presented I have a feeling that something else is in play here than what is just in side of your box.
Forgive me for possibly restating the obvious, but after looking at what you have sent and thinking about it this message is really stating that 172.20.71.1 sent an (invalid) ICMP message of type 3 code 1 (host unreachable) to a (broadcast) address of 0.0.0.0 on interface lo. This to me makes me believe that someone or something on the 172.20.71.0/24 network on eth1 sent some sort of traffic to your system with a bogus source address of 0.0.0.0 for which your system is replying. This reply which is being sent to 0.0.0.0 could be causing your kernel to send traffic back to it's self as the 0.0.0.0 means "this host" much like 127.0.0.1 does. However 0.0.0.0 is more general and has different meanings than 127.0.0.1. Seeing as how the traffic would be responded to "this host" it would be natural to do it over the loop back interface lo as it would be the fastest way to reply to "this hos
t". However your kernel is complaining about this invalid traffic on the lo interface. T
hus I have a feeling that if you sniff your eth1 interface for inbound traffic coming from the source address of 0.0.0.0 you will find that someone on your network is doing something that they should not be doing. You will then need to find out the MAC address of the inbound traffic and trace back based on who else in the network would have that MAC address.
At present I can not see any thing in your configuration that would be causing any such problems with out out side influences. As such with out any more information I don't know what else that I could do for you. If you do come up with any thing else I'd be glad to try to help, just email me and let me know.
Grant. . . .
prev parent reply other threads:[~2005-05-16 1:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-07 19:26 IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error_responses Sebastian Siewior
2005-05-09 6:09 ` Taylor, Grant
2005-05-10 13:08 ` Sebastian Siewior
2005-05-12 6:08 ` Taylor, Grant
2005-05-12 6:27 ` Sebastian Siewior
2005-05-09 15:37 ` Jason Opperisano
2005-05-12 6:50 ` Taylor, Grant
2005-05-12 7:05 ` Sebastian Siewior
2005-05-16 1:36 ` Taylor, Grant [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4287F912.8010208@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.