ResolveCollaboration
ResolveCollaboration copied to clipboard
authentication failure
On the client side (macOS) I'm seeing "Server Authentication Error: INVALID REQUEST" displayed at the bottom of the Mission Control Client window.
On the server side (win10) I see "Invalid request message (Invalid username or server password)" at the bottom of its UI window, and in the terminal window it relates:
... {'name': 'Server', 'Pk': PublicKey('TBor0Lp5z1bNPdHl7XdM4bKiuLBKpQZiUhFkgKDiFh4='), 'ip': IPv4Address('9.0.0.1')} did not decrypt message from ('10.0.1.199', 51648)
... {'name': 'zach', 'Pk': '', 'ip': '9.0.0.9'} did not decrypt message from ('10.0.1.199', 51648)
My server on the local network is at 10.0.1.101, client at 10.0.1.199. I see the same error messages when I aim the client at the WAN IP, which is port forwarded to the server. I'm definitely using the right username and password for the server, I've reset and gone through the process a few times with simpler and simpler passwords and different usernames just to be sure. The client is connecting to the server, but the authentication isn't happening. Same result happens whether the tunnel is activated or not. I've tried disabling windows firewall and that had no effect.

I've had the same symptoms recently, though not in my LAN, and was able to solve it by resetting the server and completely deleting all configurations (server and clients). From there it worked again.
I believe this is happening because of an error in versioning...
We need to merge the develop
branch to main
I added a time-based security measure to the messages sent from the Client, to make sure an attacker couldn't just re-send a packet later on and re-authenticate successfully.
On the Server side, I don't think I pushed the new security handling to the main
branch.
I plan to merge it soon, I'll update the thread when I do
Same issue here. Was this security handling problem ever addressed? Looks like this was back in September. Did anyone find a work around? Resetting the server didn't work for me.