In some set ups it has to be in others it does not [dont know the criteria], but certainly I've found for myself to need to add the IP local/remote IP addresses into the remote_hosts.cfg file [placed in the BOINC data directory [I maintain a master copy, which I replicate around to all clients when I make a change to it], whilst I use a reserved IP DHCP method, to ensure that each client maintains the same IP address. Also in my case, I then just issue the IP address or the device name into the select computer "host" box, with a standard password [same on all hosts as entered into the gui_rpc_auth.cfg file].

Critical ports are 31416 default or other port you define for a client to communicate it's RPC over. I just use port 31416 for all devices i.e. no config required.

Much simpler is though to use BOINCTasks, a 3rd party multiclient BOINC manager. Once you've set up a client connection, the manager just checks periodically if the device is up and connects automatically. At a glance in the computer view you see all your running hosts and which have connection issues. Runs native on Windows or in VM on Linux or Mac, even now on mobiles [Android ?].

OK, so that wasn't the problem.

Back to basics:

1) Is it possible to specify an arbitrary port when connecting BOINC Manager to a remote computer?

For example, when I go to "Advanced..." and "Select Computer..." can I enter "192.168.1.101:4242" and expect BOINC Manager to look for a BOINC client at 192.168.1.101 port 4242?

2) Is it possible to specify an arbitrary port on localhost in the same manner? This would be necessary for the SSH tunnel scheme I am trying to get working.

So far, BOINC Manager seems to completely ignore any specified port when I try to connect to localhost. It seems to refuse to see anything other than the local boinc client (at the default port 31416) when dealing with localhost. Which seems like bad behavior to me. Or, at least, it is the only network-aware program I've encountered that behaves this way; In my experience, SSH tunnels are normally trivially easy to set up and use.

I've seen this option before and didn't have any luck, but thanks for the link to the config file info. This looks useful; I'll give it a read and try again.



Because I have boinc clients running on all my machines, including the "control" machine where I run BOINC Manager. Reassigning 31416 to an SSH tunnel would mess up the instance of BOINC Manager controlling the local machine. The assignment of an arbitrary and high port number when establishing the tunnel is meant to avoid this.

Normally, I wouldn't bump my own old dead thread, but I've found a solution to my problem, which I'll describe here in case someone happens along later with a similar question/search.

As in my original post, I was attempting to establish an SSH tunnel as follows:

ssh -D 4242 myuser@192.168.1.101

The -D option is used to set up dynamic port-forwarding over the SSH connection. I thought this mean that SSH would accept any arbitrary traffic at local port 4242, push it across the SSH connection, and then send it along as normal. Instead, the SOCKS proxy server established by this option will not accept arbitrary traffic. It will accept only SOCKS traffic; the application attempting to connect to port 4242 must be able to speak SOCKS. BOINC manager gui rpc does not speak SOCKS -- the SOCKS configuration present in BOINC Manager is for use in accessing project servers across the internet [as when you manually request a project update], but apparently has no effect on the connection used for gui rpc. SOCKS support for gui rpc would be a nice feature to have in a future version of the Manager...

Anyway, the SSH command I should have used turns out to be:

ssh -f -L 4242:127.0.0.1:31416 myuser@192.168.1.101 sleep 120

This command allows for the forwarding of any traffic from a local port (4242) to the specified address and port at the other end of the SSH connection, on the BOINC client (127.0.0.1:31416). This command also tells SSH to run in the background (-f) and wait 120 seconds for an application to connect for port forwarding (sleep 120) before deciding that no traffic is coming and disconnecting. Thus, BOINC Manager can be told to connect to the computer at 127.0.0.1:4242, and it quite happily connects straight through the SSH tunnel and to the BOINC client running at 192.168.1.101.

remote_hosts.cfg must still be configured to allow connections from the remote machine's IP address (as the connection exiting the SSH tunnel will still appear to originate from that machine), but the default BOINC rpc port (31416) no longer needs to be open to any external network interfaces. Such is the whole point of the exercise, after all.

Now my BOINC machines need only have the one port open to a secure service (SSH port 22) instead of a whole mess of others. My portscan reports are much happier with the state of things now. The only downside (so far) is that now all of the instances of BOINC Manager sitting here on my desktop claim to be connected to to 127.0.0.1, making it difficult to tell which of my BOINC clients is which. Again, proper native support for SOCKS/SSH at the gui rpc end of things might be able to fix this.

I was actually being unclear here. The mess isn't BOINC's, but rather my own. My set up includes other programs/services that I use in conjunction with BOINC, such as apcupsd (http://www.apcupsd.org/) which can gracefully shutdown my machines in the event of a power outage. The apcupsd software isn't SOCKS aware either; now that I know how to run it over SSH, its ports need not be open either.




Or for those of us sharing a local network with other Windows users who often need us to clean out their malware infections. This Windows user prefers preventative to palliative care.