Posts by scarecrow

1) Message boards : Questions and problems : Unsolicited TCP port connection (Message 35906)
Posted 28 Nov 2010 by scarecrow
Post:
I asked the same question a while ago. I still get "New Not Syn" packets regularly from BOINC related sites that I interact with.
2) Message boards : Projects : News on project outages (Message 33150)
Posted 31 May 2010 by scarecrow
Post:
I noticed that SETI seemed to come to life momentarily, then disappeared again.
The Server/Daemon History Page showed all systems GO at 02:00 UTC, then totally gone again shortly thereafter.
3) Message boards : The Lounge : 98% of people have no interest in the projects (Message 33121)
Posted 29 May 2010 by scarecrow
Post:
Not necessarily indicative of all projects... but here's SETI




(*Active means user or host has received credits in the past 30 days)

4) Message boards : Questions and problems : Large team deleted - impossible? (Message 31550)
Posted 11 Mar 2010 by scarecrow
Post:
As usual, three cheers and/or beers to the men and women behind the curtain.

You're right. Sorry for the confusion. :-)

The team's resurrection has been put on hold until it's clear who done what.


That does it... gimme my beer back. :) :) :)
5) Message boards : Questions and problems : Large team deleted - impossible? (Message 31542)
Posted 11 Mar 2010 by scarecrow
Post:
I've never had a dog in this fight, but have been following along.
Kudos to the SETI staff for their expertise and leg work. A lot of other sites wouldn't have put forth this much effort, much less go through the hassle of a restore to rectify things. As usual, three cheers and/or beers to the men and women behind the curtain.

6) Message boards : Questions and problems : Server and unsolicited port hits (Message 24814)
Posted 10 May 2009 by scarecrow
Post:
The 'new not syn' packets don't appear to be related to the flow of work. I'm not even attached to Seti or Seti Beta, just read the message boards now and then. Just perusing the messages boards seem to generate the bad packets occasionally. However, crunching heavy for MilkyWay just about every server contact generates a bad packet. Having the firewall drop the packets, as it should do, doesn't seem to have any adverse effect... everything seems to work fine. If the servers want to waste the effort of sending packets that go nowhere it's ok with me as long it doesn't interfere with the general operation of things. :)
7) Message boards : Questions and problems : Server and unsolicited port hits (Message 24805)
Posted 9 May 2009 by scarecrow
Post:
Seti@Home -128.32.18.150 & 128.32.18.189. . The third is some FreeBSD group -195.184.98.178.


Actually, 128.32.18.189 is this (BOINC) site, 128.32.18.150 is Seti.
8) Message boards : Questions and problems : Server and unsolicited port hits (Message 24803)
Posted 9 May 2009 by scarecrow
Post:
One thing MW does differently is running the server(s) on FreeBSD instead of Linux. And had (have?) many problems getting it set up, so perhaps a misconfiguration somewhere?


Just to perpetuate the mystery a little further, I waded through the firewall logs since the first of May and discovered three other addresses that have had 'new not syn' packets dropped. And 2 of those 3 are Seti@Home -128.32.18.150 & 128.32.18.189. . The third is some FreeBSD group -195.184.98.178.
I haven't crunched for Seti for quite some time, but still read the message boards and exchange an occasional PM. I've massaged the firewall to continue to log the 'new not syn' packets, but keep them out of the operational logs, that way I can keep an eye on them and not have them clutter the day to day reports.
9) Message boards : Questions and problems : Server and unsolicited port hits (Message 24789)
Posted 8 May 2009 by scarecrow
Post:
I believe I have discovered the cause of the mystery packets the firewall is stopping. It appears that in the communication with the MW@H server, a "new not syn" packet is sent. It doesn't seem to affect the transaction with the server, I can upload, report and download fine. According to what I've read, "new not syn" packets are often the result of a broken TCP implementation, and also are said to be a common bug... by design... in MS IIS. At this point it would appear to be limited to MilkyWay, at least I'm not seeing any log entries that would indicate other projects I'm attached to are causing this sort of issue.
I don't know if this could be something that BOINC might be doing, so "for what it's worth".
At any rate, I *think* the mystery has been solved.
10) Message boards : Questions and problems : Server and unsolicited port hits (Message 24786)
Posted 8 May 2009 by scarecrow
Post:
Just fishing for answers here. In looking over my firewall logs over the several weeks I discovered that one of the most frequent IP's of dropped (firewalled) packets was MilkyWay@Home. Further investigation showed that almost every time BOINC contacted mw@h to report and/or request work, there would be a single hit on a random TCP port. As of this posting. since the first of May, it has occurred 137 times with 137 unique ports attempted to be accessed. All ports are above 32000. MW has my largest resource share right now so it's doing the most 'calling home'. Other projects have run but I see no indication of any 'hit backs' coming from their servers. I guess I'm wondering if there is something in BOINC that would cause this behavior, or if the boys over at MW better grease up the old chkrootkit program.

For what it's worth I'm running Linux 32 - BOINC 6.4.5

11) Message boards : Projects : Seti@Home is down or at least (Message 21524)
Posted 26 Nov 2008 by scarecrow
Post:
t'would appear to be an identity crisis (DNS).... if you go to the IP and not the name you waltz right in and all seems well.
12) Message boards : BOINC client : BOINC 5.10.45 on SuSe 9.2 requiring libstdc++.so.6 (Message 16768)
Posted 21 Apr 2008 by scarecrow
Post:
Just tried 5.10.45. Installs and runs fine on and older Debian box with a 2.4 kernel. But on a 2.6.19 kernel Debian machine, it installs ok, but dies instantly with this message:

./boinc: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ./boinc)


Update:
After getting onsite and looking these 2 machines over, the problem isn't kernel version, but rather 5.10.45 will not run on the current stable Debian release...a known issue. The apparent solution from other threads? Switch your Linux distro. <snicker> yeah, right... back to 5.8.16 we go.
13) Message boards : BOINC client : BOINC 5.10.45 on SuSe 9.2 requiring libstdc++.so.6 (Message 16762)
Posted 21 Apr 2008 by scarecrow
Post:
Just tried 5.10.45. Installs and runs fine on and older Debian box with a 2.4 kernel. But on a 2.6.19 kernel Debian machine, it installs ok, but dies instantly with this message:

./boinc: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ./boinc)
14) Message boards : BOINC client : Linux: problem after unexpected reboot (Message 1763)
Posted 10 Dec 2005 by scarecrow
Post:
There's one quick and dirty thing to try until they find the solution to the problem. In your case (you've lost the client_state.xml entirely) you can add a check to your scripts that start BOINC CC. If the client_state.xml file doesn't exist, don't start the BOINC CC. This way you can try to find it (either in lost+found or use client_state_prev.xml) and only then start BOINC CC.

This was in fact the aforementioned work-around. The initial fsck run went into the "unexpected problems found, rerun fsck manually" mode. The manual run found problems with client_state.xml and moved it to lost&found. Pretty easy to find in this case, it was the only file there. It's contents were not munged up at all, so copying it from lost&found back to the BOINC directory before letting boinc start back up was the 'fix' for boinc being able to pick up where it left off. The larger problem, of course, is the need for a manual run of fsck keeping the entire system from rebooting because of the problems with the boinc related file. With over 190 days of uptime on the machine running boinc before mother nature saw fit to coat us with ice and steal our electricity for 48 hours, I don't anticipate it being a major problem for me at least.

@Paul
This happened on 2 Dec so the error logs have already rotated into oblivion, and my memory is far to shot to recall the exact cause for fsck to flag client_state.xml as a problem child. If I can find anything pertinent and specfic I'll pass it along.
15) Message boards : BOINC client : Linux: problem after unexpected reboot (Message 1723)
Posted 9 Dec 2005 by scarecrow
Post:
This may not be fully accurate since unexpected reboots are usually rare, but this sequence of events has occured in both unexpected reboots I've experienced.

In a nut shell, in both occurances, client_state.xml is found to be in error and is moved to the lost&found directory. If the repairs are completed, and the final reboot back to normal continues, boinc will create a new client_state.xml, run benchmarks, download all new work, and continue on, but 'losing' any previously exising work 'being kept track of' in previous client_state.xml

This may be a fluke, or intermittent occurance, but it's happened 2 out of 2 times for me. It's not a critical show stopper, just loses work it was doing before the reboot/shutdown

I discovered a work-around the 2nd time this occured, but I don't know if it's something that will work every time. This isn't intended as a gripe or complaint, just as a heads up that should an ungraceful shutdown or reboot occur, boinc could be affected indirectly, and that with a little manual intervention, the boinc related problems may be able to be avoided with no loss of work that was in the hopper when the reboot happened.



Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.