If provider change port in sdp.json lthnvpnc client reconnection fails

[ronnylov]

Today I found an issue when using command line VPN client.
On my exit node I had changed endport port on one of the services to avoid conflict with an internal service on the server. So I uploaded sdp.json again with this new port setting and restarted lthnvpnd.

The client had previously been used with this exit node provider. It spitted out some error message (I forgot to copy that, can do it later if required). I figured this could be caused by my change of endport port on the exit node.

So on the client machine (Arch Linux) I took a look in the directory
/opt/lthn/var
In this directory there was subdirectories with different providerid/service id that I previously had connected to. I guessed that this directory store some settings from previous Connections so I removed the directory manually for this provder service.

Then I connected again and Everything worked!
So this directory might store settings that may have been changed on the exit node and make it to fail. At least the endport port change make it to fail.

[limosek]

There is caching of data downloaded from SDP.
You can change TTL by --sdp-cache-expiry SECONDS
Default is 300 seconds. It is just mechanism to not overload SDP servers by frequent fetching.
Could this be a issue?

[ronnylov]

Maybe I was too fast to connect after the change. Not sure but I can test it again.

[ronnylov]

I think the issue actually was something different. First connect attempt it asks for sudo password. It fails then. But I entered sudo password. On my Linux machine there is a timeout so if you use sudo once more right after you just used sudo you don't have to enter the sudo password. So I assumed it was the cache which also could have been an issue right after I uploaded sdp.json.

Today I got this issue without having chaged sdp.json. Noticed it worked when I tried again and it did not ask for sudo at next attempt. Should I make a new issue related to sudo usage?

[limosek]

Sudo must be configured to not ask for password. This is design issue. Even if you enter password before you run dispatcher, dispatcher needs way how to run sudo for its purposes later. And if it asks for password, it cannot continue. See https://github.com/LetheanMovement/lethean-vpn/blob/develop/conf/sudoers-lthn.conf for example how to set sudo.
Debian package will do so automatically.