I am trying to set up some remote boinccmd scripts and am getting the "Authorization failure: -155" error.

This fails:
boinccmd --host TheRemoteHost --passdw 1234...cdef --client_version
however this works:
boincmgr /n TheRemoteHost /p 1234...cdef
and I can control the remote host with the resulting manager instance, which would indicate I have the RPC configuration and firewalls set up correctly.

The machine issuing the commands is Windows 10 Home.
The remote machine is Windows 7 Pro.
Both machines were upgraded to BOINC 7.16.20 today and neither is running as a service.

This also fails on Windows 8.1 and 10 Pro remote machines with older versions of BOINC.

Any thoughts? I looked through the forum, but the issues there all seem to be Linux related issues on the same host.

RPC calls have to go through boinccmd and use the rpc_auth.cfg password file. If the salted password or the custom password don't match, you get the error.
Also the file has to be able to be read with the correct permissions. Most likely the permissions don't match the user.
You can add yourself to the boinc user group.

---

Thanks Keith,

1. Are you saying the boinccmd command I issue from one machine goes to the boinccmd instance on the remote machine? If so, then I have a firewall issue.
2. Do you mean the gui_rpc_auth.cfg password file?

Well, I added boinccmd to the remote machine firewall, that didn't solve things. So I don't think point 1 is the issue.

I'd put it slightly differently.

The remote machine needs to have a gui_rpc_auth.cfg password set. The BOINC client (not boinccmd) will be listening for that password. If you change that password, or set one for the first time, you need to re-start the BOINC client before it starts listening for the new one.

If you want to send instructions from the local machine to the remote machine, you have to send the remote machine's password from the command line on the local machine. You can get general information from the remote machine without a password, but you must send a password to make any changes.

This fails:
boinccmd --host TheRemoteHost --passdw 1234...cdef --client_version

Typo.

The boinccmd switch is

--passwd

Boinccmd tool

Well don't I feel stupid now. It was indeed the typo which was the problem all along.

Thanks Richard!

What would the command be to open the firewall to allow Boinc (and only Boinc) to communicate on port 31416?

Ubuntu 20.04 on the local client computer and Win10 on the remote manager.

To a large extent that's going to be a firewall configuration setting and is probably very dependant on the firewall(s) in question.

If it's only a standard Windows firewall then the settings are buried in the Windows Security / Firewall & Network set of screens, then find the "allow an application to..." type sub menu where you can add an application to the "white list".

Good luck.

It depends on the firewall software you use on Linux/Windows.

The generic rules would be
- on the Linux client running the BOINC cruncher

allow incoming TCP packets from any source LAN IPs/any port to dest port 31416
or (more restrictive)
allow incoming TCP packets from source [LAN IP Windows computer] any port to dest [LAN IP Linux computer] port 31416


- on the Windows computer running the remote controller (e.g. BOINC manager)

allow outgoing TCP packets from source [LAN IP Windows computer] any port to dest [LAN IP Linux computer] port 31416

It depends on the firewall software you use on Linux/Windows.

The generic rules would be
- on the Linux client running the BOINC cruncher

allow incoming TCP packets from any source LAN IPs/any port to dest port 31416
or (more restrictive)
allow incoming TCP packets from source [LAN IP Windows computer] any port to dest [LAN IP Linux computer] port 31416


- on the Windows computer running the remote controller (e.g. BOINC manager)

allow outgoing TCP packets from source [LAN IP Windows computer] any port to dest [LAN IP Linux computer] port 31416

I’m assuming ufw on Ubuntu, what I’m not sure of is whether there is any option to restrict the traffic to Boinc or whether, once opened, the port is available to traffic from any program.

I’m assuming ufw on Ubuntu, what I’m not sure of is whether there is any option to restrict the traffic to Boinc or whether, once opened, the port is available to traffic from any program.

When BOINC client starts it's RPC listener requests a network socket (like 203.0.113.27:31416) from the Linux kernel.
If this succeeds (i.e. the socket was not already in use) BOINC exclusively binds to that socket.

A network packet arriving at any interface does not include the sender/destination process name (at that protocol level), just the port number.
The packet then goes through the kernel's network stack and ends in the input buffer of the process that is connected to the destination socket.

UFW can be seen as a frontend to control the ruleset of the kernel's network stack.


So, from the perspective of the BOINC client on the linux machine:
it keeps the socket exclusively allocated until it's own end of live.

From the perspective of the network stack:
it delivers all packets allowed by the active ruleset to the destination socket but it doesn't know if they have been sent by a valid source process.
It's the BOINC client's task to check whether the network packets contain expected/valid data.

I’m assuming ufw on Ubuntu, what I’m not sure of is whether there is any option to restrict the traffic to Boinc or whether, once opened, the port is available to traffic from any program.

When BOINC client starts it's RPC listener requests a network socket (like 203.0.113.27:31416) from the Linux kernel.
If this succeeds (i.e. the socket was not already in use) BOINC exclusively binds to that socket.

A network packet arriving at any interface does not include the sender/destination process name (at that protocol level), just the port number.
The packet then goes through the kernel's network stack and ends in the input buffer of the process that is connected to the destination socket.

UFW can be seen as a frontend to control the ruleset of the kernel's network stack.


So, from the perspective of the BOINC client on the linux machine:
it keeps the socket exclusively allocated until it's own end of live.

From the perspective of the network stack:
it delivers all packets allowed by the active ruleset to the destination socket but it doesn't know if they have been sent by a valid source process.
It's the BOINC client's task to check whether the network packets contain expected/valid data.

Many thanks, that’s exactly what I needed.

Sorry to be a pest here but I’m struggling.

I’ve updated ufw to allow in port 31416

I’ve then updated my router to have a firewall rule connecting port 31416 to the IP address of my Boinc machine. I also set up a port forwarding rule to do the same.

On the laptop I want to use remotely I’ve updated the firewall to allow port 31416.

However, the laptop still connects perfectly when connected to my home Wi-Fi but fails to connect when I try using my phone as a mobile hotspot.

Is there anything I’ve missed? Anything else I can try?

STOP!

When I wrote my previous post I just described the principle assuming every connection to be made inside you own LAN segment and protected by the firewall on the internet router.

What you describe looks like a connection across your internet router and you may have opened a security hole on your router's firewall.
This is a much more complex scenario and can't be discussed here, especially since so far nobody knows what routing/firewall functions your router offers and how the have to be configured.

STOP!

When I wrote my previous post I just described the principle assuming every connection to be made inside you own LAN segment and protected by the firewall on the internet router.

What you describe looks like a connection across your internet router and you may have opened a security hole on your router's firewall.
This is a much more complex scenario and can't be discussed here, especially since so far nobody knows what routing/firewall functions your router offers and how the have to be configured.

OK, a more explicit statement of requirements :-)

I am happily using Boinc Manager from a windows 10 laptop and an iPad from within my own wi-if area to connect to and control my desktops in the garage.

However, I spend a few months each year overseas and cannot sort any problems that occur during this period.

Therefore, I would be interested in opening up access to the Boinc client from an instance of Boinc manager residing outside of my router.

I recognise that, if done incorrectly, this could be a security issue but it should be possible to open a route through the various firewalls specifically for Boinc that would not be usable by anything / anyone else.

My router is a Technicolor DWA0120 VBNT-2 at software version 18.3

Success!

I am now overseas with my laptop running TN-Grid and showing in one Boinc Manager screen whilst my desktop is showing in another Boinc Manager screen that gives me control in case of problems.

Thank you for the pointers.

Interesting that it works across the ocean.
This means the reply returns within the usual timeout.
:-)

Out of curiosity - would you mind posting the typical ping times between your laptop and the cruncher at home?
You should obfuscate the real IPs to avoid getting them swamped with unwanted packets.

Interesting that it works across the ocean.
This means the reply returns within the usual timeout.
:-)

Out of curiosity - would you mind posting the typical ping times between your laptop and the cruncher at home?
You should obfuscate the real IPs to avoid getting them swamped with unwanted packets.

Min 87.988
Ave 98.280
Max 113.985
Mdev 7.101