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

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.

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?

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.

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.

Checking for an update of the projects list in the Attach to wizard, perhaps?

---

Checking for an update of the projects list in the Attach to wizard, perhaps?

As I understand it, the packets originate from the servers.

Perhaps the BOINC server sends out the list these days. I don't know, was just a question. I have given up trying to email the developers with questions and forwarding posts from the forums as I am not getting any answers these days anyway, nor do they look here. So, perhaps that the best course of action is to email the BOINC Developers email list. (and see how your emails vanish in a super massive black hole (Muse) as well).

---

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. :)