If I run the boinc client, all seems well, but if I look at my firewall log, it frequently blocks messages from the client to the following IP addresses (these are typical; all are to port 80):
137.131.252.96
208.68.240.16
192.33.217.12
140.142.20.103
These are all BOINC applications.
My firewall blocks all outgoing messages unless they are specifically permitted (iptables under Linux). Specifically permitted are all messages going to established connections, and all messages setting up connections to port 80. So unless I have a bug in my firewall setup script, something funny is going on with the client.
The client is 5.8.16 i686-pc-linux-gnu
Could the client be taking so long, after setting up a connection, that the firewall no longer considers it an established connection?

---

137.131.252.96 = Predictor
208.68.240.16 = Fedora Core test page (not a BOINC project)
192.33.217.12 = Malariacontrol.net
140.142.20.103 = Rosetta@Home

So all, but for the FC test page are genuine BOINC projects and should be allowed to be talked to.

Could the client be taking so long, after setting up a connection, that the firewall no longer considers it an established connection?

Even if that were true, the moment BOINC tries to make contact with one of the servers, the connection would be established again. If only for a scheduler ping.
Unless said project is down.

Now, Predictor has its scheduler turned off (if all is correct).
Malaria just had some problems with its server (but file related only, not scheduler related afaik).
Rosetta has just recovered from an all-out server crash. It was down for about a week.

---

137.131.252.96 = Predictor
208.68.240.16 = Fedora Core test page (not a BOINC project)
192.33.217.12 = Malariacontrol.net
140.142.20.103 = Rosetta@Home

So all, but for the FC test page are genuine BOINC projects and should be allowed to be talked to.

Could the client be taking so long, after setting up a connection, that the firewall no longer considers it an established connection?

Even if that were true, the moment BOINC tries to make contact with one of the servers, the connection would be established again. If only for a scheduler ping.
Unless said project is down.

Now, Predictor has its scheduler turned off (if all is correct).
Malaria just had some problems with its server (but file related only, not scheduler related afaik).
Rosetta has just recovered from an all-out server crash. It was down for about a week.

If the various projects are down, why would MY firewall deny the BOINC client permission to send do it? Should I just not get a response or something?

Here is a typical one (line split up for neatness):

Sep 9 03:13:16 trillian kernel: IPT Out FIREWALL: IN= OUT=eth0
SRC=192.168.0.251 DST=137.131.252.96 LEN=52 TOS=0x00 PREC=0x00 TTL=64
ID=54634 DF PROTO=TCP SPT=57455 DPT=80
WINDOW=91 RES=0x00 ACK FIN URGP=0

I assume ACK FIN is the last step in taking down the connection (but I could be wrong about this). But they are not all the same:

Sep 9 03:13:17 trillian kernel: IPT Out FIREWALL: IN= OUT=eth0
SRC=192.168.0.251 DST=140.142.20.103 LEN=52 TOS=0x00 PREC=0x00 TTL=64
ID=9133 DF PROTO=TCP SPT=53766 DPT=80
WINDOW=54 RES=0x00 ACK PSH FIN URGP=0

---

Connection to the outside world are initiated by BOINC, for security sake. Once decided to attach to a project it should only contact your attached projects, thus I think it save to simply allow BOINC in the firewall to go outside via port 80 and for the rare project using secure connection, port 443. If not happy with that broadness, set up an IP group with those IP addresses you have confirmed with port 80 and 443. Associate that group to BOINC. They dont's change too often, thus little maintenance is needed.

I guess I am not clear.

My firewall allows my machine to ESTABLISH a connection to any IP address on port 80. And any established connection can be replied to. So once I am connected as I imagine FireFox does, it goes along OK.

But there is something different about the way the BOINC client does it that gets all these rejects.

---

My firewall allows my machine to ESTABLISH a connection to any IP address on port 80. And any established connection can be replied to. So once I am connected as I imagine FireFox does, it goes along OK.

But there is something different about the way the BOINC client does it that gets all these rejects.

The fact is that most of BOINC projects run on shoe-string. Which means that servers are generally under-powered for amount of requests they get and thusly response is a bit less than immediate many times. When things go haywire, one may see all sort of funny (or not so funny). I wouldn't be much surprised if I saw long and sporadic delays when connecting to some project server.

If your FW rules impose too strict timing, then it may occasionally seem that you get some sort of inbound connection from project server while in reality it's only a very late response.

I'm doing some statistics on real use of internet by many broadband and dial-up users and I've found out that sometimes a live TCP connection can have pauses as long as 10 minutes before they resume. Go figure ...

---

Metod ...

My firewall allows my machine to ESTABLISH a connection to any IP address on port 80. And any established connection can be replied to. So once I am connected as I imagine FireFox does, it goes along OK.

But there is something different about the way the BOINC client does it that gets all these rejects.

The fact is that most of BOINC projects run on shoe-string. Which means that servers are generally under-powered for amount of requests they get and thusly response is a bit less than immediate many times. When things go haywire, one may see all sort of funny (or not so funny). I wouldn't be much surprised if I saw long and sporadic delays when connecting to some project server.

If your FW rules impose too strict timing, then it may occasionally seem that you get some sort of inbound connection from project server while in reality it's only a very late response.

I'm doing some statistics on real use of internet by many broadband and dial-up users and I've found out that sometimes a live TCP connection can have pauses as long as 10 minutes before they resume. Go figure ...

Well, I do not explicitly set the timing in the firewall (Linux iptables firewall with Linux kernel 2.6.18-8.1.8.el5PAE); I just take what I get, and it works for all other IP addresses, but seems to fail for BOINC ones. Not all the time, or course, or I could not get any work done.

---