Subject: Re: Problem w/SETI Queue. Possibly from latest SETI Spy?
From: "newsreader" <newsreader@wyvernhall.com>
Date: 16/09/2003, 22:22
Newsgroups: alt.sci.seti

"Martin" <ml_news@ddnospamddml1dd.co.uk.dd> wrote in message
news:MsJ9b.1202$I9.733@newsfep4-winn.server.ntli.net...
newsreader wrote:
"Martin" <ml_news@ddnospamddml1dd.co.uk.dd> wrote in message
Damnifiknow.  Probably some Windows Updates from MicroSloth but nothing
else
common to both affected systems.  This setup has been running fine for
months with virtually no changes.

Such is the danger of blind automagical no-warning behind your back
'others know better' updates to help you along with extra 'features'...

Give me *some* credit...  No automagic updates here, but there's always the
possibility that one of the recent patches I manually applied to fix known
Windoze security holes screwed something else up.

Some more data points:
S@h (NT CLI 3.03) has no problem connecting directly with Berkeley if I
remove the proxy info for SETI Queue.
SETI Queue shows no evidence of connection attempts from the affected
machines in its logs.
A port scan from the affected machine has no trouble seeing the SETI
Queue
server on port 5517.

OK, so on what systems and how?

Both affected systems happen to be on WinME.  (But other WinME systems are
chugging along just fine.)

I haven't fiddled with the HOSTS file yet but I'm doubtful it will help.
If
it can't connect to an explicit IP address,

Well, I also was rather surprised at how clunky the windoze system is.
It wouldn't surprise me if it was looking up a text name that is
192.168.blah.blaf rather than _using_ the _numbers_ ! I might try putting:

I would be surprised if that was the case.  In any event, it's not something
that would have changed out of the blue.

in the hosts file for a laugh to see if magically works. Or it might be
a foobar on the part of the s@h GUI client coding.

That I couldn't tell you -- I haven't had the GUI running on anything in
years.

I wouldn't think the results
would be any better connecting to that same address after forcing the
machine to look it up in HOSTS.

Infinitely better when it can get the correct IP address!

Except that I know it already has the correct IP address.  It's explicitly
stated and the S@h client is displaying the correct IP when it makes its
connect attempt...

Consider carefully any side effects to whatever you have disturbed.
Unless you're suffering bad hardware, computers are completely
deterministic.

Identical hardware issues from out of nowhere are unlikely on two systems at
once.  =)

There's got to be a common denominator somewhere....

(However, windoze introduces enough randomness and inconsistency to
confound everyone.)

Despite all the anti-MicroSloth hype, I've never had any real issues with
Windoze.  In my experience, a Windoze system configured with the same level
of care necessary to configure a *nix system well is, IMHO, just as
reliable.  The problem is that even a sloppily configured Windoze system can
be made to run even if it can't be made to run well. =>