unable to service request at this time

[j0110]

Hi, When using this executable to upgrade the tunnel connection, I often get this error: unable to connect ephemeral peer, rpc error: code = Unknown desc = unable to service request at this time If I wait a minute, it works again, but I can't understand why it does nor work the first time. Thanks

[mvd-ows]

This is currently being looked into. Will update here once resolved.

[mvd-ows]

We've corrected a config issue in the general area where your client request is being processed. However, the specific error message you're seeing should not be produced even running with the non-optimal config.

Would you mind sharing some examples of relays where you've seen this error?

[j0110]

Tested today, and I got the same issue, it is with fr-par-wg-001. But I got the same issue with other servers too.

For info, I use this script to execute the upgrade : https://github.com/j0110/mullvad-controller/blob/main/starter.py

[mvd-ows]

Trying to upgrade an already upgraded peer will be rejected by the server. This is likely what's happening here.

The error is being returned to the client with a generic error message to prevent exploration of server state.

You could extend your script to check if the active peer already has a PSK configured and then avoid attempting a second upgrade.

[j0110]

Well, this script is used as as Post-Activation so no PSK is set at that time... If the script is run as Post-Activation it fails, but if I wait few seconds and run it manually, it works... Strange !

[mvd-ows]

Here's a patch release that will detect invalid attempts to upgrade the tunnel: https://github.com/mullvad/wgephemeralpeer/releases/tag/v1.0.4

The binary will now abort with an error if you attempt to upgrade an already upgraded tunnel. Please try this new version and update us on your success.

[j0110]

I got surprisingly a new error : unable to connect to relay, ensure you are able to connect to 10.64.0.1 on TCP port 1337 Strange, because 10.64.0.1 is pingable before trying to attempt to upgrade the tunnel... Same error even if I had a delay of 1sec just after the ping test is successful.

[mvd-ows]

You local firewall is likely interfering with communications. Can you confirm that mullvad-upgrade-tunnel does indeed work when used with wg-quick, without all the extra steps?

[j0110]

Same... PostUp = "C:\Program Files\mullvad-controller\mullvad-upgrade-tunnel.exe" -wg-interface %WIREGUARD_TUNNEL_NAME%

2024-10-01 14:44:19.440: [TUN] [m_FR.par] Executing: `"C:\Program Files\mullvad-controller\mullvad-upgrade-tunnel.exe" -wg-interface %WIREGUARD_TUNNEL_NAME%`
2024-10-01 14:44:30.253: [TUN] [m_FR.par] cmd> unable to connect to relay, ensure you are able to connect to 10.64.0.1 on TCP port 1337
2024-10-01 14:44:30.268: [TUN] [m_FR.par] Command error exit status: 1
2024-10-01 14:44:30.268: [TUN] [m_FR.par] An error occurred while running a configuration script command: A generic command executable returned a result that indicates failure.
2024-10-01 14:44:30.454: [TUN] [m_FR.par] Shutting down
2024-10-01 14:44:30.464: [MGR] [m_FR.par] Tunnel service tracker finished

[mvd-ows]

Alright, you seem to have a firewall and/or routing issue. Remove the PostUp and with a tunnel established, ensure that you can connect to 10.64.0.1:1337 over TCP. Since you're on Windows, use curl or ncat to test connectivity.

[j0110]

Well, 10.64.0.1:1337 is accessible. I can perform manually the tunnel upgrade after the tunnel was established, but it won't works as a PostActivation action. Therefore I don't think it is a firewall/routing issue.

[mvd-ows]

Interesting. We'll do some testing on this end and get back to you.

[mvd-ows]

We've retested this on Win10 and Win11 and found no issues.

Keep in mind that the PostUp action runs in the context of the SYSTEM user. Is it possible that you could have configuration or security software that prevents that user from making the required connection?

In the event that there's a timing issue involved, it may help to insert a pause before attempting to upgrade the tunnel.

There are some restrictions related to this, e.g. it's not trivial to chain PostUp commands using the Windows implementation of Wireguard, and also, the timeout system utility cannot be used in this context.

Create a separate script file hack-upgrade-tunnel.bat with the following content:

powershell -nop -c "& {sleep 3}"
mullvad-upgrade-tunnel -wg-interface %1

And you'll need to adjust the PostUp:

PostUp = hack-upgrade-tunnel.bat %WIREGUARD_TUNNEL_NAME%

Let us know if that makes any difference.