Folding Forum

I am trying to allow remote access to the folding client but it's not working. v7.4.4 on Windows 7.

I have added my local network (192.168.1.0/24) to the allow list in FAHcontrol for both password and no-password. I have tried setting a password and also tried leaving it blank but when I add the client on another machine it just shows "connecting" and never connects. Nothing is logged.

With the web control, I tried connecting to 192.168.1.190:7396 and that is logged with - "WARNING:Denied 81:192.168.1.192 access to URI: /"
I can't see any options for the web control in FAHcontrol at all.

nmap confirms that the remote machine is listening on both 36330 and 7396, so this isn't a firewall issue.

The sample-config.xml file seems to suggest that you can control the web control with "<web-allow>127.0.0.1 x.x.x.x</web-allow>", but its syntax does not seem to match the config.xml, so I suspect that may be out of date. I tried adding web-control 127.0.0.1 192.168.1.192 in the expert options in FAHcontrol and it seemed to recognise this, but it still didn't allow any access.

Can't find any docs for this. Any help most be most appreciated.

I never used the fah remote access functionality. I just remote in to my PC using nomachine and administer FAH as if I was at home on the PC. Easy. For my two other folding rigs I also just use nomachine to connect from my primary PC. Even when remoteing in to my main PC then remoting from it into my other two rigs there is no noticeable lag.

I know for sure it’s working as I remote connect from my iOS devices to my folding rigs in several locations. Though those are all Linux Boxen it worked also with Win 7 during tests.

Q1: can you just try to “telnet <ip.> 36330 “ and tell us error messages; if any ?
Q2: can you share the config.xml from the remote side (remove passkey and password)

Telnet opens the connection, but no error message, or anything else, appears to be transmitted.

Here is the config:

Whenever you change the Remote access settings, FAHClient must be restarted. Those settings are only processed during initialization. [I don't know how many times I made changes which didn't work because I was assuming the update I just entered was being used.) [Grrr.)

The setting '127.0.0.1 192.168.1.192' is wrong. That enables exactly TWO IP addresses. You probably mean '127.0.0.1,192.168.1.0/24' (which enables your entire subnet ... and then restart FAH)

Ah! Sorted it! It seems that some changes require a restart of FAHclient but others don't. Should have tried that really.
Anyway, I can now connect remotely from either FAHcontrol or browser.

Thanks bruce! The config I posted there was just the latest one I had tried, I just wanted to test the simplest one possible. I had already tried 192.168.1.0/24 and 192.168.1.0-192.168.1.255 before.

You can use 192.168.1.0-192.168.1.255 if you'd rather but DO NOT LEAVE OUT 127.0.0.1

registered for an account just to come in here and thank bruce for this. This comes up at the top of a Google search for: folding at home problems with remote clients

bruce wrote:Whenever you change the Remote access settings, FAHClient must be restarted.

I have two systems running, one Windows with 8 CPUs and one old Mint Linux with 2 CPUs. Both are running well seperately.
Now I want to monitor both systems from the other.
I have everything setup as described, I think.
The config is done, I can telnet into the remote system.
I stopped an started the server process.
Via the remote access the other client is connected now and seems to be online, but when I click on the other client, everything is grayed out and
it says "Updating" but never finishes.
This problem exists in both directions, means from the Linux system to the Windows system and vice versa.
Both systems are of course in the same network without any firewall in between.

Any ideas?

I had similar problems with current V7.5.1

I have 2 machines on Windows 10. They appear to be online and hard at work.
Then I have 4 machines on Ubuntu Server 18.04 running as headless services.
Firstly when I start the service, systemctl reports a failure, yet the process still runs and writes to the log and nothing in the log seems to indicate a failure or reason for concern.
It then works perfectly fine until I configure remote access and restart the service.
It will initially come up just fine on FAHControl but then quickly descend into an ever lasting updating state and the CPU on the machine will be at idle.

From what I can see, the client does not stop, therefore it probably does not start clean either. I have to stop it, then go find the process ID and kill it, then start again.
That brings it to life quickly. I suspect the failure to stop leaves residual PID or lock files on disk which then throws the start up routine into a loop trying to find or match up previous PID or lock states.

I have also tried to restart the machine, but it just goes back to this same state, so most likely a PID or lock file persisted on disk.

When I kill the client, a child thread dies with it and it is able to recover on start again.
Once it is running in a good state, I can safely reload the process without any problems, just net restart.

Right, so all of that might help the developer find the bug, in the interim, this is what I did to restore it.

Instead of using the kill command, there is a linux command you can use to restart the FAHClient process. First pause all folding, then: Some versions of init.d have a restart option that will do both for you. This will be cleaner than using kill.

Another person posting here gave the following step by step directions - viewtopic.php?f=16&t=32962&p=316215&hilit=remote+access#p316067 - for setting up remote access. That may help.

Thanks Joe_H

I seem to get the same behaviour with calling the unit file via full path or via the service command.
Stop does not appear to stop it and leaves some processes still active.

However, when there were no processes running and I started it up, I can do a reload without any problems.
I have also noticed that the machines tend to report no WU available after a while, but if I do a reload, it will pick up a WU within a minute or so. Coincidence? Perhaps.

Solved on my side.
The problem was that you have to enter the IP address in two places, "IP address restriction" AND "Passwordless IP address restriction".

I'm new and have three machines running. One W10 and two Debian headless, while the W10 should also show the two headless systems.
I followed the discussion here but it seems that the "command port" 36330 is only open on the local 127.0.0.1 device. Connecting to the external device, even from the specific machine itself, telnet connection fails.
So how can I activate the external port? I did an all machines the standard installation with no custom config, except the account information of course.