191.1.1.5 sent an invalid ICMP error to a broadcast

191.1.1.5 sent an invalid ICMP error to a broadcast

Post by Peter Caffi » Tue, 11 May 1999 04:00:00



Hi guys,

There are two Linux PCs at the office, a number of Win95 PCs and a number
of SCO UNIX PCs. There's one SCO UNIX PC that's been causing error
messages to pop up on my logs (and to the console) for ages.

We're trying to kill off a Novell Netware server here, and I really want
to remove this as being a potential source of problems. Unfortunately, the
owner of the box considers it "not his problem" (remind me to rant on
a.s.r sometime).

This is an example of what's appearing in my /var/log/messages on the main
Linux server:

May  6 11:40:16 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  6 12:25:20 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  6 13:16:52 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  6 14:25:35 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  6 17:25:58 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  6 17:25:58 stm0150 last message repeated 3 times
May  6 17:31:32 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  6 17:31:40 stm0150 last message repeated 10 times
May  6 18:02:07 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  6 18:32:16 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  6 19:31:58 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  6 19:32:00 stm0150 last message repeated 4 times

[...]
May  9 15:36:44 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  9 15:36:44 stm0150 last message repeated 5 times
May  9 19:37:22 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  9 19:37:22 stm0150 last message repeated 5 times
May  9 21:37:41 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  9 21:37:41 stm0150 last message repeated 5 times
May  9 23:38:00 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May  9 23:38:00 stm0150 last message repeated 5 times
May 10 01:38:18 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
broadcast
May 10 01:38:18 stm0150 last message repeated 5 times

It *seems* to be patterned-ish, but, not.. Anyone from the SCO world (or
the Linux world) have any suggestions on what might be causing this sort
of behaviour? 191.1.1.5 is the SCO system.

--:     _           _    _ _
 _oo__ |_|_ |__  _ |  _ |_|_o _  pc at it dot net dot a u |
//`'\_ | (/_|(/_|  |_(_|| | || |            it.net.au/~pc |
/                 PO Box 869, Hillarys WA 6923, AUSTRALIA |

 
 
 

191.1.1.5 sent an invalid ICMP error to a broadcast

Post by Jeff Lieberma » Tue, 11 May 1999 04:00:00



I like detective stories, interesting problems and guesswork.

Quote:>There are two Linux PCs

That's nice.  Any particular flavour?  Version?  IP addresses?  Clues?

Quote:>at the office, a number of Win95 PCs and a number
>of SCO UNIX PCs.

I didn't know that all SCO Unix versions were identical.  Any particular
product or version?  You must be trying to be intentionally vague.  Does "a
number" mean anything specific?  Are you a mystery writer?

Quote:>There's one SCO UNIX PC that's been causing error
>messages to pop up on my logs (and to the console) for ages.

Any particular one?  My guess is 191.1.1.5 but it might be one of the
"other" SCO Unix PC's from your description.  Hard to tell.

Quote:>We're trying to kill off a Novell Netware server here, and I really want
>to remove this as being a potential source of problems. Unfortunately, the
>owner of the box considers it "not his problem" (remind me to rant on
>a.s.r sometime).

Since you know about alt.tech-support.recovery, then I suggest you apply a
self-lart for blabbering this question.  what does this unspecified version
of Novell Netware have to do with this?  Is it running TCP/IP?  Is it's
name stm0150?  Is it broadcasting something that the SCO box would fail to
appreciate?  Why should only one Linux machine complain?

Quote:>This is an example of what's appearing in my /var/log/messages on the main
>Linux server:

Oh, it's the "main" Linux server.  Anything in syslog?

Quote:>May  6 11:40:16 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
>broadcast

I'll assume that stm0150 is the main Linux server.

Quote:>May  6 12:25:20 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
>broadcast

OK.  Let's convert the error message from Linux into English.  stm0150 sent
a broadcast.  191.1.1.5 (the unspecified SCO box) sent a reply via ICMP
that the Linux box failed to appreciate.  The shopping list of likely
culprits are bootp, IPX/SPX SAP (server advertising protocol), DHCP server
announcements, and such.  I'm really guessing as there's not enough info to
make a positive identification.  Dive into /usr/adm/syslog ON BOTH MACHINES
and see if a protocol name or number is specified.

Quote:>May  6 13:16:52 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
>broadcast

Whatever is doing this, repeats itself 5 or 10 times every 20 seconds.
Something on the Linux box is configured to do something on the SCO box and
fails to appreciate whatever the SCO box is returning.

Quote:>It *seems* to be patterned-ish, but, not.. Anyone from the SCO world (or
>the Linux world) have any suggestions on what might be causing this sort
>of behaviour?

SCO World and Linux World are both magazines.  Why would you want a
magazine editor or publisher to answer your question?

Quote:> 191.1.1.5 is the SCO system.

Ummmmm, gee thanks.  Out of curiousity, duz your company own 191.1.1.5 or
is this borrowed from someone?  Is this network connected to the interknot?
Are the error messages continuous or only appear when connected to the
interknot?  

Sigh.  Another day, another guess.

--
Jeff Liebermann  150 Felker St #D  Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.cruzio.com/~jeffl   WB6SSY


 
 
 

191.1.1.5 sent an invalid ICMP error to a broadcast

Post by Peter Caffi » Tue, 11 May 1999 04:00:00




> I like detective stories, interesting problems and guesswork.
>>There are two Linux PCs
> That's nice.  Any particular flavour?

Largely irrelevant, I'd have thought. Debian 2.0/2.1 hybrid.

Quote:>Version?

Kernel 2.2.7.

Quote:>IP addresses?

191.1.1.150 ... Linux Server.
191.1.1.149 ... My Linux workstation.
191.1.1.5   ... Suspect SCO workstation.

Quote:>Clues?

Now, now, no need to be sarky.

Quote:>>at the office, a number of Win95 PCs and a number
>>of SCO UNIX PCs.
> I didn't know that all SCO Unix versions were identical.  Any particular
> product or version?

Openserver 5.04 or 5.05.

Quote:> You must be trying to be intentionally vague.  Does "a
> number" mean anything specific?  Are you a mystery writer?

Nope, actually I got interrupted mid-post by people who needed the modem.
Such is life in the technological wastelands. My connection to this here
net (while at work) consists of a 2400 bps terminal session. This modem is
shared between 3 people. Further whinging will be seen on a.t-s.r, don't
you worry. However this is not the place.

Quote:>>There's one SCO UNIX PC that's been causing error
>>messages to pop up on my logs (and to the console) for ages.
> Any particular one?  My guess is 191.1.1.5 but it might be one of the
> "other" SCO Unix PC's from your description.

Yup. 191.1.1.5 is a SCO Openserver 5.04 workstation.

Quote:>>We're trying to kill off a Novell Netware server here, and I really want
>>to remove this as being a potential source of problems. Unfortunately, the
>>owner of the box considers it "not his problem" (remind me to rant on
>>a.s.r sometime).
> Since you know about alt.tech-support.recovery, then I suggest you apply a
> self-lart for blabbering this question.
> what does this unspecified version of Novell Netware have to do with
> this?

Motive supplied was my reason for tracking this down. Otherwise, well,
the SCO ping is not a serious problem (apart from screen clutter).

Quote:> Is it running TCP/IP?  Is it's name stm0150?

Now why would Novell Netware report in /var/log/messages format? ;)

Quote:> Is it broadcasting something that the SCO box would fail to
> appreciate?

No other SCO systems systems are broadcasting crap. Further, niether Linux
box contains mention of the SCO system at all (aside from in /etc/hosts).

Quote:> Why should only one Linux machine complain?

Both Linux systems complain, actually. The one listed was an example.

Quote:>>This is an example of what's appearing in my /var/log/messages on the main
>>Linux server:
> Oh, it's the "main" Linux server.  Anything in syslog?

Not a thing.

Quote:>>May  6 11:40:16 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
>>broadcast
> OK.  Let's convert the error message from Linux into English.  stm0150 sent
> a broadcast.  191.1.1.5 (the unspecified SCO box) sent a reply via ICMP
> that the Linux box failed to appreciate.  The shopping list of likely
> culprits are bootp, IPX/SPX SAP (server advertising protocol), DHCP server
> announcements, and such.  I'm really guessing as there's not enough info to
> make a positive identification.  Dive into /usr/adm/syslog ON BOTH MACHINES
> and see if a protocol name or number is specified.

Good advice. Ta.

Quote:>>May  6 13:16:52 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
>>broadcast
> Whatever is doing this, repeats itself 5 or 10 times every 20 seconds.
> Something on the Linux box is configured to do something on the SCO box and
> fails to appreciate whatever the SCO box is returning.

Shouldn't be. The same errors appear on the Linux workstation which
doesn't serve.

Quote:>>It *seems* to be patterned-ish, but, not.. Anyone from the SCO world (or
>>the Linux world) have any suggestions on what might be causing this sort
>>of behaviour?
> SCO World and Linux World are both magazines.  Why would you want a
> magazine editor or publisher to answer your question?

Sarky again? There's a difference between the .recovery newsgroups and
the informational newsgroups, IMHO. We're all clueless about some things
sometimes (see Scott Adams "The Dilbert Zone"), which is why these sorts
of support newsgroups are *y useful.

I try to keep to at *least* a 4:1 ratio of helping posts for every
request for help. Turning a support newsgroup into the same one-up-manship
contest that a.t-s.r (but far more frequently a.s.r) can become, isn't
something I'd like to see here, IMHO.

Quote:>> 191.1.1.5 is the SCO system.
> Ummmmm, gee thanks.  Out of curiousity, duz your company own 191.1.1.5 or
> is this borrowed from someone?  Is this network connected to the interknot?

Nope, nyet and no.

And no, I have no control over the numbering. And yes, I informed the
individual concerned about the correct ranges last year.

At this stage, we're UUCP-only apart from our local LAN, so the numbering
is an irrelevant issue vastly tangental to this posting.

--:     _           _    _ _
 _oo__ |_|_ |__  _ |  _ |_|_o _  pc at it dot net dot a u |
//`'\_ | (/_|(/_|  |_(_|| | || |            it.net.au/~pc |
/                 PO Box 869, Hillarys WA 6923, AUSTRALIA |

 
 
 

191.1.1.5 sent an invalid ICMP error to a broadcast

Post by Bill Vermilli » Tue, 11 May 1999 04:00:00





>> 191.1.1.5 is the SCO system.
>Ummmmm, gee thanks. Out of curiousity, duz your company own
>191.1.1.5 or is this borrowed from someone? Is this network
>connected to the interknot? Are the error messages continuous or
>only appear when connected to the interknot?

191.1.1.5 is from a reserved block according to IANA.

So while not the proper address at least it won't route anywhere.
--

 
 
 

191.1.1.5 sent an invalid ICMP error to a broadcast

Post by Jeff Lieberma » Wed, 12 May 1999 04:00:00



Quote:>Largely irrelevant, I'd have thought. Debian 2.0/2.1 hybrid.
>>Version?
>Kernel 2.2.7.
>>IP addresses?
>191.1.1.150 ... Linux Server.
>191.1.1.149 ... My Linux workstation.
>191.1.1.5   ... Suspect SCO workstation.

Product names and version numbers are very important.  Different version
have slightly different syslog formats and have some known bugs which might
relevent to the problem.  The more *NUMBERS* you supply, the easier it is
to visualize what you're running.

Quote:>Openserver 5.04 or 5.05.

Since the 3.2v5.0.4 server is originating the broadcasts, does this server
have all the required updates installed?  See:
        http://www.veryComputer.com/
for the recommended minimum patch list.  Specifically, RS504C and OSS469C
corrected a substantial number of bugs.  Run:
        swconfig
for a list of what's installed.  I don't know if it has anything to do with
the problem, but it's signifigant that the 3.2v5.0.5 server does not belch
the same broadcasts.  Besides the OS version, is there any major
configuration differences in:
        /etc/inetd.conf
        /etc/services
files, especially items in inetd.conf

Quote:>> Is it running TCP/IP?  Is it's name stm0150?
>Now why would Novell Netware report in /var/log/messages format? ;)

Sorry.  I wasn't brutal enough.  You brought up decomishioning an
unspecified version of Novell Netware for an unspecified reason.  I was
wondering why you added this to the puzzle, whether it had anything at all
to do with the broadcast problem, and whether the Novell box has the TCP/IP
NLM's loaded.  If it's 3.12, I had a hell of time with these NLM's doing
all manner of digusting things to the network.  After about 3 major updates
from Netwire, the problems finally settled down long enough for me to throw
out the box and replace it with an NT box and effectively start over.

Quote:>No other SCO systems systems are broadcasting crap. Further, niether Linux
>box contains mention of the SCO system at all (aside from in /etc/hosts).

If all the various machines share the same class C address space and the
netmasks do not specify a sub-net, then every machine will see every other
machine.  A broadcast by one will be seen by all.

Quote:>> Why should only one Linux machine complain?
>Both Linux systems complain, actually. The one listed was an example.

Are you sure you're not a mystery writer?  Obtaining information by
interrogation is a useful technique.  Torture is more effective, but
difficult to apply via news and email.

Quote:>>>May  6 11:40:16 stm0150 kernel: 191.1.1.5 sent an invalid ICMP error to a
>>>broadcast

>> OK.  Let's convert the error message from Linux into English.  stm0150 sent
>> a broadcast.  191.1.1.5 (the unspecified SCO box) sent a reply via ICMP
>> that the Linux box failed to appreciate.  The shopping list of likely
>> culprits are bootp, IPX/SPX SAP (server advertising protocol), DHCP server
>> announcements, and such.  I'm really guessing as there's not enough info to
>> make a positive identification.  Dive into /usr/adm/syslog ON BOTH MACHINES
>> and see if a protocol name or number is specified.

>Good advice. Ta.

Yeah, but not an answer.  Lacking numbers and real information, like the
protocol name or services number that's failing, I have to play detective
and try to deduce the problem.  The rather odd timing of the errors had me
baffled until you casually disclosed that both Linux boxes were
complaining.  That will explain why sometimes it barfed 5 times and
sometimes 10 times.  BOTH Linux boxes are broadcasting something and both
are complaining that SCO 3.2v5.0.4 fails to appreciate the broadcasts.

Now, what would a Debian 2.1 box upgraded to 2.2 be doing broadcasting the
same thing on two different machines that uses ICMP.  There's not much that
uses ICMP (Internet Control Message Protocol).  Unfortunately, I left my RH
5.1 Linux box off when I left the office so I can't check.  I know ping,
traceroute, SCO's copy protection daemon, RIP (router info protocol) and
other routing protocols, use ICMP.

Hmmm...  Your Debian boxes must have routed running and are belching RIP2
packets, while the 3.2v5.0.4 SCO box only knows RIP1, doesn't know anything
about RIP2 and is complaining about the format.  The 3.2v5.0.5 box does
RIP2 so it doesn't complain.

In such an isolated lan, you don't need routed running.  Kill the routed
daemons on the SCO boxes (it won't hurt) and see if the messages go away.
If you've got gated running, kill it too.  If that works, find the line
that starts routed in /etc/tcp on the SCO boxes and comment it out.  Same
on the Linux boxes.

Quote:>Sarky again? There's a difference between the .recovery newsgroups and
>the informational newsgroups, IMHO. We're all clueless about some things
>sometimes (see Scott Adams "The Dilbert Zone"), which is why these sorts
>of support newsgroups are *y useful.

Different?  I thought this was alt.tech-support.recovery.  Terribly sorry.
Please forgive my rakeing you over the coals and subtle attempts at
*, degredation and mockery for not supplying any numbers or
information.

Quote:>I try to keep to at *least* a 4:1 ratio of helping posts for every
>request for help. Turning a support newsgroup into the same one-up-manship
>contest that a.t-s.r (but far more frequently a.s.r) can become, isn't
>something I'd like to see here, IMHO.

I tried being nice, but it didn't work.  I've been answering questions in
the SCO newsgroups since they emerged from the old biz.* newsgroups.  If
someone asks a question, but doesn't supply enough information (such as the
product name and version), they receive the full benifit of my wrath.  If
they do supply the necessary information, they get my best guess answer,
which I assume is somewhat better than my wrath.

Incidentally, I think my ratio of questions to supplying answers is about
500:1.  I vaguely recall asking 2 questions in about 10 years.  Deja.com
shows about 2200 messages by me since 1993.

Quote:>And no, I have no control over the numbering. And yes, I informed the
>individual concerned about the correct ranges last year.

Eventually, you're going to get burned.  My very first IP LAN was based on
the assumption that it would never hit the internet.  So, I picked a random
IP range.  Three years later, I got to help reconfigure about 100 boxes
splattered accross 5 locations.  T'was no fun.  Fix it now while you're
still sane.

Quote:>At this stage, we're UUCP-only apart from our local LAN, so the numbering
>is an irrelevant issue vastly tangental to this posting.

Assumption, the mother of all screwups.  I could concoct a likely senario
where it does make a difference, but you answered my question.
Incidentally, I still get most of my email via UUCP.  Now, disarm routed
and tell us what happens.

--
Jeff Liebermann  150 Felker St #D  Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.veryComputer.com/~jeffl   WB6SSY

 
 
 

1. blah sent up an invalid ICMP error to a broadcast.

I have an OpenBSD firewall appliance that is reporting to its console:

AAA.BBB.CCC.DDD sent up an invalid ICMP error to a broadcast.

The other interesting thing about this is that the address
AAA.BBB.CCC.DDD is an internal interface on the OpenBSD firewall
appliance, the same device that is reporting it.

Does anyone have any clues as to what is going on here?

Thanks
Ben

2. host name resolve

3. gateway sends an invalid ICMP error to a broadcast(?!)

4. Problem with Matrox Millennium II Graphics Server in XFree86

5. <gatewayIP> sent an invalid ICMP error to a broadcast

6. ST02-controller with modern SCSI-drive?

7. gateway sends an invalid ICMP error to a broadcast(?!)

8. Customer Survey

9. make icmp.c be more verbose on broadcast icmp errors

10. 2.5.70 invalid icmp broadcast.

11. Invalid ICMP Error???

12. invalid ICMP type 11 error when Samba is running

13. "invalid ICMP error" messages