newsreader wrote:

"Martin" <ml_news@ddnospamddml1dd.co.uk.dd> wrote in message

[...]

What else has changed in any way?

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


[...]

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?


[...]

I tried using both the "proper" static IP and the local network 192.168...
IP for the SETI Queue server with the same results either way.  The client
machine just won't connect to transfer data yet it accesses the SETI Queue
web interface just fine.  (Your problem sounds familiar.  Were you using ICS
on the LAN?  If so, you need to explicitly configure ICS to direct tcp port
5517 to the SETI Queue server.)

Nope. I'm using Mandrake 9.1 Linux, iptables and masquerading on my gateway. The media machine of a certain large company might call it "ICS" to sound good.

The fix: You must enter the host _name_ that is then looked up with DNS
(or WINS, or from a local hosts or lmhosts file)!

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:

192.168.xxx.xxx        192.168.xxx.xxx
192.168.xxx.xxx        host01.some.domain

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.

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!

SetiSpy should not in any way affect s@h operation unless you get file
access permissions strangeness. This may be a problem if you are working
across network mounted directories...

I managed to rule out SETI Spy (Sorry for doubting you Roeloef! =) -- it was
apparently just a coincidence that I upgraded about the same time this
started happening.

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

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


Good luck,
Martin