• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

SETI problem..

amdxborg

amdxborg

Diamond Member
Are there some really big Seti classic wu going around? Some of my clients shows seti using 100%cpu but the wu takes sometimes days to finish on a P4 3Ghz?

This is really getting me down and with this being just another in a series of probs like the people at my company complaining about network usage, I fear my seti days may be coming to an end or I might have to slow down a bit.. 🙁

edit.. Found the problem in the setiqueue log, the clients were returning duplicate results and sq was not showing a wu was returned.. from where the duplicates suddenly came I've got no idea! Anybody else have a problem like this?
 
I've gotten some bad workunits in the past that have caused such behavior. I've just had to delete them. I haven't seen it very often.

Bad news about the problems. Especially for we Borgs. 🙁
 
On your system(s) that run SetiQueue, search for the "hosts" file using Windows Explorer. Edit it in a text editor (notepad is fine) and add a line at the end like this:

66.28.250.122 shserver2.ssl.berkeley.edu

(The IP and the server name are separated by a space or a tab character.)

If every one of your clients transmits to your setiqueue system, then that is the only one you need to worry about. In other words, any system that transmits directly to Berkeley should have the line above added to the hosts file.

The exploit requires a spoof entry to be added to the DNS cache on the system transmitting wu's to direct requests intended for Berkeley to a different system. TCP/IP always looks to the hosts file before looking at DNS to resolve host names so adding the line to your hosts file will always direct requests to Berkeley's IP regardless of what's in your DNS cache.

The above was posted by OD on another forum. I just copy and pasted it.
 
Originally posted by: Freewolf
Originally posted by: Wolfsraider
Originally posted by: Ronin
Hrmm...if you're running 3.03, you DO have it patched, right?
Click to expand...

Patched?
Click to expand...

I don't remember the details but 3.03 had a security hole in it and the patch closed it.
Click to expand...

Adding the following line to you hosts file of any computer that connect directly to the Berkeley servers closed the v3.03 security hole:

66.28.250.122 shserver2.ssl.berkeley.edu

Ken_g6 & Ohiodude had a better explaination in this thread.

I've never had much luck with SETI Q. I could get it to work OK on one computer but when i had other comps on my network connect to it i had serious dup problems & lost too many WUs.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top