Quote:>Largely irrelevant, I'd have thought. Debian 2.0/2.1 hybrid.
>188.8.131.52 ... Linux Server.
>184.108.40.206 ... My Linux workstation.
>220.127.116.11 ... 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:
for the recommended minimum patch list. Specifically, RS504C and OSS469C
corrected a substantial number of bugs. Run:
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:
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.
>>>May 6 11:40:16 stm0150 kernel: 18.104.22.168 sent an invalid ICMP error to a
>> OK. Let's convert the error message from Linux into English. stm0150 sent
>> a broadcast. 22.214.171.124 (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
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
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