IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error

All of lore.kernel.org
 help / color / mirror / Atom feed

* IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error_responses
@ 2005-05-07 19:26 Sebastian Siewior
  2005-05-09  6:09 ` Taylor, Grant
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Sebastian Siewior @ 2005-05-07 19:26 UTC (permalink / raw)
  To: netfilter

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Hallo,

My kernel complaints himself every second with:

kernel: XX.XX.XX.XX sent an invalid ICMP type 3, code 1 error to a
broadcast: 0.0.0.0 on lo

In the meantime I supressed the messages via  

echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses". 

Other people solved this problem with 

iptables -A INPUT -i lo -j ACCEPT

but it won't work here. Does someone have an idea how I could find out
where the packets are comming from?

-- 
Mit freundlichem Gruß
Sebastian Siewior

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error_responses
  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-09 15:37 ` Jason Opperisano
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 9+ messages in thread
From: Taylor, Grant @ 2005-05-09  6:09 UTC (permalink / raw)
  To: netfilter

Sebastian Siewior wrote:
> Hallo,
> 
> My kernel complaints himself every second with:
> 
> kernel: XX.XX.XX.XX sent an invalid ICMP type 3, code 1 error to a
> broadcast: 0.0.0.0 on lo
> 
> In the meantime I supressed the messages via  
> 
> echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses". 
> 
> Other people solved this problem with 
> 
> iptables -A INPUT -i lo -j ACCEPT
> 
> but it won't work here. Does someone have an idea how I could find out
> where the packets are comming from?

Can we get an iptables-save output as well as an ifconfig -a?  I'm betting that something is preventing traffic from flowing to or from your lo interface.



Grant. . . .


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error_responses
  2005-05-09  6:09 ` Taylor, Grant
@ 2005-05-10 13:08   ` Sebastian Siewior
  2005-05-12  6:08     ` Taylor, Grant
  0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Siewior @ 2005-05-10 13:08 UTC (permalink / raw)
  To: netfilter


[-- Attachment #1.1: Type: text/plain, Size: 369 bytes --]

On Mon, 09 May 2005 01:09:15 -0500
"Taylor, Grant" <gtaylor@riverviewtech.net> wrote:

> Can we get an iptables-save output as well as an ifconfig -a?  I'm
> betting that something is preventing traffic from flowing to or from
> your lo interface.
> 
I attached ifconfig and rules with substituted IPs.
> 
> 
> Grant. . . .
> 
> 

-- 
Sebastian Siewior

[-- Attachment #1.2: ifconfig_s --]
[-- Type: application/octet-stream, Size: 3328 bytes --]

eth0      Link encap:Ethernet  HWaddr 00:
          inet addr:172.20.15.26  Bcast:172.20.15.27  Mask:255.255.255.252
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9572724 errors:15660 dropped:15660 overruns:0 frame:0
          TX packets:7890307 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2248211894 (2.0 GiB)  TX bytes:2262924714 (2.1 GiB)
          Base address:0xa400 Memory:fe9c0000-fe9e0000 

eth1      Link encap:Ethernet  HWaddr 00:
          inet addr:172.20.71.1  Bcast:172.20.71.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8849876 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11995074 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1544972900 (1.4 GiB)  TX bytes:2682128189 (2.4 GiB)
          Base address:0xa800 Memory:fe9e0000-fea00000 

eth2      Link encap:Ethernet  HWaddr 00:
          inet addr:172.20.68.254  Bcast:172.20.68.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:145519 errors:0 dropped:0 overruns:0 frame:0
          TX packets:270211 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:12153761 (11.5 MiB)  TX bytes:363070192 (346.2 MiB)
          Base address:0x8800 Memory:fe780000-fe7a0000 

eth3      Link encap:Ethernet  HWaddr 00:
          inet addr:172.20.78.254  Bcast:172.20.78.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12230064 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10795059 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1776946173 (1.6 GiB)  TX bytes:465976636 (444.3 MiB)
          Base address:0x9000 Memory:fe7a0000-fe7c0000 

eth4      Link encap:Ethernet  HWaddr 00:
          inet addr:172.20.73.254  Bcast:172.20.73.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1238591 errors:0 dropped:0 overruns:0 frame:0
          TX packets:802702 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1432060568 (1.3 GiB)  TX bytes:89206643 (85.0 MiB)
          Base address:0x9400 Memory:fe7c0000-fe7e0000 

eth5      Link encap:Ethernet  HWaddr 00:
          inet addr:172.20.67.254  Bcast:172.20.67.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:897368 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1077866 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:92243804 (87.9 MiB)  TX bytes:1233771956 (1.1 GiB)
          Base address:0x9800 Memory:fe7e0000-fe800000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:30954 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30954 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:5774706 (5.5 MiB)  TX bytes:5774706 (5.5 MiB)


[-- Attachment #1.3: rules_s --]
[-- Type: application/octet-stream, Size: 10190 bytes --]

# Generated by iptables-save v1.3.0 on Tue May 10 14:40:26 2005
*raw
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
[0:0] -A PREROUTING -p tcp -m iprange --src-range 172.20.64.0-172.20.65.254 -m multiport --dports 80,22 -j ACCEPT 
[0:0] -A PREROUTING -p tcp -m iprange --dst-range 172.20.64.0-172.20.65.254 -m multiport --sports 80,22 -j ACCEPT 
[0:0] -A PREROUTING -m iprange --src-range 172.20.64.0-172.20.65.254 -j NOTRACK 
[0:0] -A PREROUTING -m iprange --dst-range 172.20.64.0-172.20.65.254 -j NOTRACK 
[0:0] -A PREROUTING -p tcp -m iprange --src-range 172.20.33.0-172.20.47.254 -m multiport --dports 80,22 -j ACCEPT 
[0:0] -A PREROUTING -p tcp -m iprange --dst-range 172.20.33.0-172.20.47.254 -m multiport --sports 80,22 -j ACCEPT 
[0:0] -A PREROUTING -m iprange --src-range 172.20.33.0-172.20.47.254 -j NOTRACK 
[0:0] -A PREROUTING -m iprange --dst-range 172.20.33.0-172.20.47.254 -j NOTRACK 
[0:0] -A PREROUTING -p tcp -m iprange --src-range 172.20.70.0-172.20.70.254 -m multiport --dports 80,22 -j ACCEPT 
[0:0] -A PREROUTING -p tcp -m iprange --dst-range 172.20.70.0-172.20.70.254 -m multiport --sports 80,22 -j ACCEPT 
[0:0] -A PREROUTING -m iprange --src-range 172.20.70.0-172.20.70.254 -j NOTRACK 
[0:0] -A PREROUTING -m iprange --dst-range 172.20.70.0-172.20.70.254 -j NOTRACK 
[0:0] -A PREROUTING -p tcp -m iprange --src-range 172.20.130.0-172.20.131.254 -m multiport --dports 80,22 -j ACCEPT 
[0:0] -A PREROUTING -p tcp -m iprange --dst-range 172.20.130.0-172.20.131.254 -m multiport --sports 80,22 -j ACCEPT 
[0:0] -A PREROUTING -m iprange --src-range 172.20.130.0-172.20.131.254 -j NOTRACK 
[0:0] -A PREROUTING -m iprange --dst-range 172.20.130.0-172.20.131.254 -j NOTRACK 
COMMIT
# Completed on Tue May 10 14:40:26 2005
# Generated by iptables-save v1.3.0 on Tue May 10 14:40:26 2005
*nat
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
[0:0] -A PREROUTING -s ! 172.20.78.0/255.255.255.0 -d ! 172.20.0.0/255.255.0.0 -p tcp -m tcp --dport 80 -m state --state NEW -j DNAT --to-destination 172.20.78.42:80 
COMMIT
# Completed on Tue May 10 14:40:26 2005
# Generated by iptables-save v1.3.0 on Tue May 10 14:40:26 2005
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
COMMIT
# Completed on Tue May 10 14:40:26 2005
# Generated by iptables-save v1.3.0 on Tue May 10 14:40:26 2005
*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [0:0]
[0:0] -A FORWARD -i lo -j ACCEPT 
[0:0] -A FORWARD -o lo -j ACCEPT 
[0:0] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
[0:0] -A FORWARD -p icmp -m icmp --icmp-type 8 -m length --length 50:100 -m limit --limit 10/sec -j ACCEPT 
[0:0] -A FORWARD -p icmp -m icmp --icmp-type 8 -j DROP 
[0:0] -A FORWARD -p icmp -m limit --limit 10/sec --limit-burst 3 -j ACCEPT 
[0:0] -A FORWARD -s 172.20.71.2 -i eth1 -j ACCEPT 
[0:0] -A FORWARD -d 172.20.71.2 -o eth1 -j ACCEPT 
[0:0] -A FORWARD -s 172.20.64.150 -d 172.20.79.10 -p tcp -m tcp --dport 25 -j ACCEPT 
[0:0] -A FORWARD -s 172.20.64.50 -d 172.20.79.10 -p tcp -m tcp --dport 25 -j ACCEPT 
[0:0] -A FORWARD -s 172.20.64.55 -d 172.20.79.10 -p tcp -m tcp --dport 25 -j ACCEPT 
[0:0] -A FORWARD -s 172.20.64.150 -d 172.20.78.10 -p tcp -m tcp --dport 25 -j ACCEPT 
[0:0] -A FORWARD -s 172.20.64.50 -d 172.20.78.10 -p tcp -m tcp --dport 25 -j ACCEPT 
[0:0] -A FORWARD -s 172.20.64.55 -d 172.20.78.10 -p tcp -m tcp --dport 25 -j ACCEPT 
[0:0] -A FORWARD -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -m iprange --src-range 172.20.64.0-172.20.65.254 -m state --state NEW,UNTRACKED -j ACCEPT 
[0:0] -A FORWARD -m iprange --dst-range 172.20.64.0-172.20.65.254 -m state --state NEW,UNTRACKED -j ACCEPT 
[0:0] -A FORWARD -m iprange --src-range 172.20.33.0-172.20.47.254 -m state --state NEW,UNTRACKED -j ACCEPT 
[0:0] -A FORWARD -m iprange --dst-range 172.20.33.0-172.20.47.254 -m state --state NEW,UNTRACKED -j ACCEPT 
[0:0] -A FORWARD -m iprange --src-range 172.20.70.0-172.20.70.254 -m state --state NEW,UNTRACKED -j ACCEPT 
[0:0] -A FORWARD -m iprange --dst-range 172.20.70.0-172.20.70.254 -m state --state NEW,UNTRACKED -j ACCEPT 
[0:0] -A FORWARD -m iprange --src-range 172.20.130.0-172.20.131.254 -m state --state NEW,UNTRACKED -j ACCEPT 
[0:0] -A FORWARD -m iprange --dst-range 172.20.130.0-172.20.131.254 -m state --state NEW,UNTRACKED -j ACCEPT 
[0:0] -A FORWARD -s 172.20.78.20 -i eth3 -j ACCEPT 
[0:0] -A FORWARD -d 172.20.78.20 -o eth3 -j ACCEPT 
[0:0] -A FORWARD -d 172.20.73.1 -p tcp -m multiport --dports 22,2401,80,8080,8443,443,1099 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.73.2 -p tcp -m multiport --dports 22,2401,80,8080,8443,443,1099 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.73.4 -p tcp -m multiport --dports 22,80,8080 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.73.5 -p tcp -m multiport --dports 21,22,80,3306,5800,5900 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.73.6 -p tcp -m multiport --dports 22 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.73.7 -p tcp -m multiport --dports 22 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.73.8 -p tcp -m multiport --dports 22,80,443,8080 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.73.9 -p tcp -m multiport --dports 22,80,3690 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.73.101 -p tcp -m multiport --dports 22,25,80,443 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.73.121 -p tcp -m multiport --dports 22,25,80,443 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.73.1 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.73.2 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.73.4 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.73.5 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.73.6 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.73.7 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.73.8 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.73.9 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.73.101 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.73.121 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.78.10 -p tcp -m multiport --dports 22,25,53,123,80,443,4443 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.78.12 -p tcp -m multiport --dports 22,80,443 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.78.13 -p tcp -m multiport --dports 22,80,443 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.78.42 -p tcp -m multiport --dports 22,80,8080 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.78.44 -p tcp -m multiport --dports 22,80,8080 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.78.80 -p tcp -m multiport --dports 22,80,443 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.78.99 -p tcp -m multiport --dports 22 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.78.10 -p udp -m multiport --dports 53,123 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.78.42 -p udp -m multiport --dports 8080 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.78.44 -p udp -m multiport --dports 8080 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.78.10 -p tcp -m multiport --dports 22,25,53,123,80,443,4443 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.78.12 -p tcp -m multiport --dports 80 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.78.42 -p tcp -m multiport --dports 22,80,443 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.78.44 -p tcp -m multiport --dports 22,80,8080,53 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.78.80 -p tcp -m multiport --dports 22,80,443,53 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.78.10 -p udp -m multiport --dports 53,123 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.78.42 -p udp -m multiport --dports 53 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.78.44 -p udp -m multiport --dports 8080,53 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.78.80 -p udp -m multiport --dports 53 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.67.0/255.255.255.0 -p tcp -m multiport --dports 22 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.67.0/255.255.255.0 -p tcp -m multiport --dports 22,80,110,143,443,993,995,1194,5190,5222,5223,6667,873,3690 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.67.0/255.255.255.0 -p udp -m multiport --dports 53,1194,500 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.67.0/255.255.255.0 -p esp -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.67.0/255.255.255.0 -p ah -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -d 172.20.68.0/255.255.255.0 -p tcp -m multiport --dports 22 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.68.0/255.255.255.0 -p tcp -m multiport --dports 22,80,110,143,443,993,995,1194,5190,5222,5223,6667,873,3690 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.68.0/255.255.255.0 -p udp -m multiport --dports 53,1194,500 -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.68.0/255.255.255.0 -p esp -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -s 172.20.68.0/255.255.255.0 -p ah -m state --state NEW -j ACCEPT 
[0:0] -A FORWARD -j REJECT --reject-with icmp-port-unreachable 
[0:0] -A INPUT -i lo -j ACCEPT 
[0:0] -A INPUT -s 172.20.227.21 -j ACCEPT 
[0:0] -A INPUT -s 172.20.225.140 -j ACCEPT 
[0:0] -A INPUT -s 172.20.73.8 -j ACCEPT 
[0:0] -A INPUT -s 172.20.64.60 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
[0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
[0:0] -A INPUT -p icmp -m icmp --icmp-type 8 -m length --length 50:100 -m limit --limit 10/sec -j ACCEPT 
[0:0] -A INPUT -p icmp -m icmp --icmp-type 8 -j DROP 
[0:0] -A INPUT -p icmp -m limit --limit 10/sec --limit-burst 3 -j ACCEPT 
[0:0] -A INPUT -s 172.20.71.2 -i eth1 -j ACCEPT 
[0:0] -A INPUT -p tcp -j TARPIT 
COMMIT
# Completed on Tue May 10 14:40:26 2005

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error_responses
  2005-05-10 13:08   ` Sebastian Siewior
@ 2005-05-12  6:08     ` Taylor, Grant
  2005-05-12  6:27       ` Sebastian Siewior
  0 siblings, 1 reply; 9+ messages in thread
From: Taylor, Grant @ 2005-05-12  6:08 UTC (permalink / raw)
  To: netfilter

> I attached ifconfig and rules with substituted IPs.

> kernel: XX.XX.XX.XX sent an invalid ICMP type 3, code 1 error to a broadcast: 0.0.0.0 on lo

Can I get a source IP address in place of the XX.XX.XX.XX?



Grant. . . .


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error_responses
  2005-05-12  6:08     ` Taylor, Grant
@ 2005-05-12  6:27       ` Sebastian Siewior
  0 siblings, 0 replies; 9+ messages in thread
From: Sebastian Siewior @ 2005-05-12  6:27 UTC (permalink / raw)
  To: netfilter

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

On Thu, 12 May 2005 01:08:12 -0500
"Taylor, Grant" <gtaylor@riverviewtech.net> wrote:

> Can I get a source IP address in place of the XX.XX.XX.XX?
> 
172.20.71.1

> 
> Grant. . . .
> 
> 
-- 
Mit freundlichem Gruß
Sebastian Siewior

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error_responses
  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-09 15:37 ` Jason Opperisano
  2005-05-12  6:50 ` Taylor, Grant
  2005-05-16  1:36 ` Taylor, Grant
  3 siblings, 0 replies; 9+ messages in thread
From: Jason Opperisano @ 2005-05-09 15:37 UTC (permalink / raw)
  To: netfilter

On Sat, May 07, 2005 at 09:26:28PM +0200, Sebastian Siewior wrote:
> Hallo,
> 
> My kernel complaints himself every second with:
> 
> kernel: XX.XX.XX.XX sent an invalid ICMP type 3, code 1 error to a
> broadcast: 0.0.0.0 on lo
> 
> In the meantime I supressed the messages via  
> 
> echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses". 
> 
> Other people solved this problem with 
> 
> iptables -A INPUT -i lo -j ACCEPT
> 
> but it won't work here. Does someone have an idea how I could find out
> where the packets are comming from?

ICMP Type 3 Code 1 == Destination Unreachable, Host Unreachable

seems odd that you would be sending/receiving those on lo.  i suppose
they could be caused by not having rules that allow traffic on loopback:

  iptables -A INPUT -i lo -j ACCEPT
  iptables -A OUTPUT -o lo -j ACCEPT

but you say these don't fix the problem?

you may be able to pick out an offending packet by watching:

  tcpdump -n -nn -p -i lo -s 1500 icmp

as a proper ICMP 3/1 packet should have the original packet header
in-tact as the data of the packet.

-j

--
"Peter: Make like Siamese twins and split... and then one of you die."
        --Family Guy


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error_responses
  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-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
  3 siblings, 1 reply; 9+ messages in thread
From: Taylor, Grant @ 2005-05-12  6:50 UTC (permalink / raw)
  To: netfilter

Sebastian Siewior wrote:
> Hallo,
> 
> My kernel complaints himself every second with:
> 
> kernel: XX.XX.XX.XX sent an invalid ICMP type 3, code 1 error to a
> broadcast: 0.0.0.0 on lo
> 
> In the meantime I supressed the messages via  
> 
> echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses". 
> 
> Other people solved this problem with 
> 
> iptables -A INPUT -i lo -j ACCEPT
> 
> but it won't work here. Does someone have an idea how I could find out
> where the packets are comming from?

Would it be possible to get an output of your routing table?  I'm starting to think that this *might* be a routing issue that somehow your kernel thinks that systems are available via the wrong interface.



Grant. . . .


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error_responses
  2005-05-12  6:50 ` Taylor, Grant
@ 2005-05-12  7:05   ` Sebastian Siewior
  0 siblings, 0 replies; 9+ messages in thread
From: Sebastian Siewior @ 2005-05-12  7:05 UTC (permalink / raw)
  To: netfilter

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

On Thu, 12 May 2005 01:50:43 -0500
"Taylor, Grant" <gtaylor@riverviewtech.net> wrote:

> 
> Would it be possible to get an output of your routing table?  I'm
> starting to think that this *might* be a routing issue that somehow
> your kernel thinks that systems are available via the wrong interface.
> 

default via 172.20.1.25 dev eth0 
172.20.1.24/30 dev eth0  proto kernel  scope link  src 172.20.1.26 
172.20.130.0/24 via 172.20.71.2 dev eth1 
172.20.131.0/24 via 172.20.71.2 dev eth1 
172.20.33.0/24 via 172.20.71.2 dev eth1 
172.20.34.0/24 via 172.20.71.2 dev eth1 
172.20.35.0/24 via 172.20.71.2 dev eth1 
172.20.36.0/24 via 172.20.71.2 dev eth1 
172.20.37.0/24 via 172.20.71.2 dev eth1 
172.20.38.0/24 via 172.20.71.2 dev eth1 
172.20.39.0/24 via 172.20.71.2 dev eth1 
172.20.40.0/24 via 172.20.71.2 dev eth1 
172.20.41.0/24 via 172.20.71.2 dev eth1 
172.20.42.0/24 via 172.20.71.2 dev eth1 
172.20.43.0/24 via 172.20.71.2 dev eth1 
172.20.44.0/24 via 172.20.71.2 dev eth1 
172.20.45.0/24 via 172.20.71.2 dev eth1 
172.20.46.0/24 via 172.20.71.2 dev eth1 
172.20.47.0/24 via 172.20.71.2 dev eth1 
172.20.64.0/24 via 172.20.71.2 dev eth1 
172.20.65.0/24 via 172.20.71.2 dev eth1 
172.20.67.0/24 dev eth5  proto kernel  scope link  src 172.20.67.254 
172.20.68.0/24 dev eth2  proto kernel  scope link  src 172.20.68.254 
172.20.70.0/24 via 172.20.71.2 dev eth1 
172.20.71.0/24 dev eth1  proto kernel  scope link  src 172.20.71.1 
172.20.73.0/24 dev eth4  proto kernel  scope link  src 172.20.73.254 
172.20.78.0/24 dev eth3  proto kernel  scope link  src 172.20.78.254 



> 
> 
> Grant. . . .
> 
> 


-- 
Sebastian Siewior

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error_responses
  2005-05-07 19:26 IP sent an invalid ICMP type to a broadcast and icmp_ignore_bogus_error_responses Sebastian Siewior
                   ` (2 preceding siblings ...)
  2005-05-12  6:50 ` Taylor, Grant
@ 2005-05-16  1:36 ` Taylor, Grant
  3 siblings, 0 replies; 9+ messages in thread
From: Taylor, Grant @ 2005-05-16  1:36 UTC (permalink / raw)
  To: netfilter

> 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. . . .

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2005-05-16  1:36 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 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.