Folding Forum

Tested assign3.foldingathome.org:80 in the chrome browser and it works.

I've verified the personal firewall on my computer is off, and the office firewall has whitelisted both the F@H application and all of the servers' IP addresses. If the firewall is still blocking F@H after all that, how can we fix it?

One thing I probably should have mentioned earlier: I'm using Teamviewer to remotely access my office workstation. Could this be creating an issue?

Previously when I have used TeamViewer, it wouldn't cause any issues for downloading WUs and connecting to the Servers.

On some firewalls, if the port 80/8080 connection isn't started by an internet browser, it will be blocked since the firewall thinks that it is non-standard. See if your Internal IT team would be keen to look into that. Alternatively, they can log a case with SonicWall and make it their problem if they have the support contract.

Ask your IT team if they use a proxy server. FAH can be configured to use one if that would be helpful. That might change how ports 8080/80 respond.

PantherX: the IT dept whitelisted the FAH application in the firewall. That should allow the 80/8080 connection thru, right? Or is there a separate thing we need to do to allow 80/8080 thru?

Bruce: we don't have a proxy server, checked with IT.

We do use Trend Micro for company-wide Antivirus, could that be causing the issue?

Some firewalls block connection by IP number by default, but allow connection to named addresses looked up via DNS. Someone posted on that happening with his connections within the last month or two. For his firewall, he used a temporary workaround of periodically connecting by the server names, after that the IP number connections used by the client would go through. Might be a similar problem with the SonicWall.

No idea on the Trend Micro AV, but some AV software has their own requirements for exceptions.

By "periodically connecting by the server names," do you mean copy / pasting the url from the FAH log into my web browser?
I tried that and some sort of file got downloaded, but it doesn't appear to have fixed the problem.

I forget whether his script just ping'd them or opened up the server address by name to reach the landing page. He took those server names from the Server Status page. As I understood it, that access cached an entry in the local DNS which equivalenced the name and IP number, i.e. connecting to nnn.nnn.nnn.nnn was the same as 'abc'.'tld'

Eventually he found where to set the firewall to allow connection by IP number instead of using the workaround.

That work-around sounds a bit beyond my skill level haha. And I'm trying to start an office team, so I'm not sure I can reasonably expect everyone to use this work around.

We've whitelisted the IP address, and I've also mentioned to our IT team that FAH uses explicit IP instead of DNS. These changes changed the error log, but didn't resolve the issue.

I was looking thru the Program Files directory just now and saw that there are several application files. Do all of those need to be whitelisted or just "FAHClient"?

Just FAHClient makes connections outside of the system it is running on. The other application files only communicate locally with FAHClient and each other in some cases.

Anyways, I went back and looked at the 3rd log you posted, some progress is visible. To give context of where things are, I am going to give an outline of what the different components of the client do, and will try to keep it from getting too long. Some may be more understandable by your IT people.

FAHClient is meant to run in the background, it manages downloads, uploads, and starting and stopping of WUs to be run. It also maintains a log from messages generated in other components. It has open ports on the local IP address 127.0.0.1 to connect to other components, 36330 for FAHControl and the folding cores, and 7396 (I think I got that right) for connections for the Web Control.

Web Control as provided is just a link to F@H servers to get a javascript that connects to FAHClient and displays information about the running WU and provides rudimentary configuration and control.

FAHControl, also known as Advanced Control, provides additional control and monitoring functions, connects over port 36330.

FAHViewer only displays the WU being worked on, do not recall if it uses 36330 or a different port, not essential to working on F@h but the display can be interesting.

On Windows I forget whether you will also see in the same location FAHCore_nn executables or FAHCoreWrapper, they are involved in the actual running of the WU and are started in a separate process by FAHClient. FAHCore_nn executables are downloaded separately from the client installer.

Okay, FAHControl and FAHClient is working mostly okay in the 3rd log. The firewall changes so far have allowed FAHClient to connect to an Assignment Server, get assigned to one of the Work Servers and download a WU.

The first thing the client needs to do if the folding core needed has not been used before or the current WU needs an updated version, is download the core. That is where things stuck this time: As bruce mentioned in his post, often that is on the server end, but the "Failed to read stream" can be from firewall or AV blocking a file transfer of the executable file. Or you may need an additional address whitelisted, looking up cores.foldingathome.org the IP address is 65.254.110.241 currently.

Hope something here helps, feel free to ask for any clarification.

IT has whitelisted all of these IP addresses on this list: https://apps.foldingathome.org/serverstats

65.254.110.241 isn't on the list, so I'll ask them to whitelist that one too. Are there any other IP addresses not included on this list that will need to be whitelisted?

I can't think of any for now. You may need to recheck the Server Status page every so often, F@h may get use of additional servers donated in the future. But it shouldn't change as fast and as often as it was in late March through April.

I believe the folding cores used to download from one of the AS's, but may not be recalling that right. A number of server related items and locations changed due to reconfigurations to meet the big increase in participation after the announcements that F@h would be doing COVID-19 related research in mid-March.

It's working!!!! Thank you to everyone that offered their help in fixing this, y'all are awesome!

Good to hear. Remote diagnosing these is hard at times and every setup is a bit different. So it is nice to know when there is a successful outcome.