Jump to content

Hello! 👋

These forums are now archived (read only).

Join us on Discord.

Since beta, unable to connect to auto-config server


Recommended Posts

Since the update to the newest beta (I could even see this during the not using the latest version message)

I'm getting an "There was a problem connecting to the auto-config service" error.

Here's logs from one of the computers:

https://synergy-logs.symless.com/2017-10-30/4376-2017-10-30T14-58-58.log

Things were working before the update.

I tried restarting program and services.

 

Edited by Canterrain
Link to post
Share on other sites

Hello Nick!

Yes, I tried that yesterday to no avail.

The service log is basically filled with the following:

 

[ Service ] [2017-10-31T07:01:24] debug: websocket handshake error 3: WebSocket Upgrade handshake failed
[ Service ] [2017-10-31T07:01:24] error: websocket connection error
[ Service ] [2017-10-31T07:01:24] debug: retrying websocket connection in 1s
[ Service ] [2017-10-31T07:01:25] debug: retrying websocket connection now
[ Service ] [2017-10-31T07:01:25] debug: connecting websocket

 

Both machines I'm trying currently are running Windows 10 fall creators update, one is on insider previews the other is not.

 

The machine that is not is behind bitdefender, the machine that is on insider is just behind Defender.

There is a corporate firewall involved, but this was working prior to this latest beta, and nothing has changed about the systems or firewall in question.

A reboot of my system running insider previews did not help.

 

Link to post
Share on other sites

Yes, they both said the same thing.

I went into the second log file I found in that location (log1 for extension, I renamed the file to get into it with an editor).

One device the log was the same as above.

The other device (the machine on Insider Preview, Windows Defender)

did have this:

 

[ Service ] [2017-10-30T13:49:37] debug: saying hello to config ui
[ Service ] [2017-10-30T13:49:37] debug: config ui opened, forcing connectivity test
[ Service ] [2017-10-30T13:49:37] debug: handling local profile screen set changed, mode=unknown
[ Service ] [2017-10-30T13:49:38] error: can't send profile snapshot, not yet received from cloud
[ Service ] [2017-10-30T13:49:42] debug: retrying websocket connection now
[ Service ] [2017-10-30T13:49:42] debug: connecting websocket
[ Service ] [2017-10-30T13:49:42] debug: websocket handshake error 3: WebSocket Upgrade handshake failed
[ Service ] [2017-10-30T13:49:42] error: websocket connection error
[ Service ] [2017-10-30T13:49:42] debug: retrying websocket connection in 7s
[ Service ] [2017-10-30T13:49:49] debug: retrying websocket connection now
[ Service ] [2017-10-30T13:49:49] debug: connecting websocket
[ Service ] [2017-10-30T13:49:49] debug: websocket handshake error 3: WebSocket Upgrade handshake failed
[ Service ] [2017-10-30T13:49:49] error: websocket connection error

Link to post
Share on other sites
  • Synergy Team
Nick Bolton
16 hours ago, Canterrain said:

Alas, no dice when following those uninstall instructions.  No change in the logs on the error either.

When you reinstalled, did it prompt you to "Sign in with Symless" again?

Link to post
Share on other sites

It did not, which is a bit surprising since you had me delete appdata\local symless folders.

Is sign info perhaps stored in the registry somewhere? (That'd be unusual, but not the first time I've seen that)

I'm pretty comfortable working in registry and so on.

Link to post
Share on other sites
  • Synergy Team
Nick Bolton
2 hours ago, Canterrain said:

Is sign info perhaps stored in the registry somewhere? (That'd be unusual, but not the first time I've seen that)

 

The guide says to delete these keys, did you do that?

  • HKEY_CURRENT_USER\Software\Symless
  • HKEY_CURRENT_USER\Software\Synergy
Link to post
Share on other sites

Hello Nick,

I .. didn't. I swear I looked over those instructions twice and missed the registry steps both times.  I handle Support Tier 3 as one of my duties, so I can only lay the blame upon myself.

Unfortunately, I'm still not any better off.  Just for complete clarity, here's what I did after reading your reply:

1) I uninstalled Synergy via the Control Panel

2) I went to registry and deleted:

HKEY_CURRENT_USER\Software\Symless
T
he other key listed was not found

3) I went to %ProgramData% and deleted the Symless folder.
The other folder listed was not found.

4) I went to File Explorer and opened:

%USERPROFILE%\AppData\Local
Then deleted the Symless folder, the other folder was not found.

5) Rebooted

6) Reinstalled Synergy 2 by downloading a fresh installer through Microsoft Edge

This time I saw a sign in screen.  I clicked on that, was automatically signed in thanks to saved passwords... and then saw the error again.

One thing that stands out to me, I still do not see a:
C:\ProgramData\Synergy v2
folder.  Just a
C:\ProgramData\Symless
folder.

 

Link to post
Share on other sites
  • Synergy Team
Nick Bolton

Hmm, so it's maybe not an issue with the session.

Are you behind a corporate proxy/firewall?

Link to post
Share on other sites

Yes. We're using a Fortigate firewall that I have access to.

The previous beta didn't have any issues, but this still might be a good area to explore as the Fortigate can be.. finicky.

Anything in particular I can look for there?

Link to post
Share on other sites
  • Synergy Team
Nick Bolton
Just now, Canterrain said:

The previous beta didn't have any issues

We changed the port from the non-standard 8081 in beta4 to the standard 443 SSL port in beta5.

Could you double check that the C:\ProgramData\Symless\Synergy\synergy-user.cfg file was definitely deleted?

9 minutes ago, Canterrain said:

I still do not see a:
C:\ProgramData\Synergy v2

That was from an older beta, it's not used any more.

Link to post
Share on other sites

C:\ProgramData\Symless\Synergy\synergy-user.cfg

Was definitely deleted, shows todays date and a recent timestamp.  Looks to be recreated each time I start.


However, 

18 minutes ago, Nick Bolton said:

We changed the port from the non-standard 8081 in beta4 to the standard 443 SSL port in beta5.

This might be the problem.  I think, off the top of my head, the firewall does inspection of traffic over port 443.  There's an exception in place for HTTPS websites, but I'm guesting the data Synergy is sending is getting intercepted.

Edit: Looks like the firewall actually has signature exceptions for Synergy as an option built in, but activating those didn't help. Probably cause they're based on Synergy 1 I would guess.

Edited by Canterrain
Link to post
Share on other sites
  • Synergy Team
Nick Bolton
4 minutes ago, Canterrain said:

This might be the problem.  I think, off the top of my head, the firewall does inspection of traffic over port 443.  There's an exception in place for HTTPS websites, but I'm guesting the data Synergy is sending is getting intercepted.

I wonder what your sysadmin would have to say?

Link to post
Share on other sites
12 minutes ago, Nick Bolton said:

I wonder what your sysadmin would have to say?

I'm a wear many hats kind of guy.

**Puts on Sysadmin hat**

I say... I shall find a way to make a safe exception!

I think this will be on me from here.  If I find a good and reasonable solution that balances my need for Synergy to do its awesome work with the security I'm supposed to maintain with the firewall, I'll post it in this thread.

It's quite possible it's something pretty straight forward, just don't have immediate time to spend in the firewall settings.

FWIW there are some optional synergy signatures built into the firewall already that can be activated, however they don't alleviate the issue currently (I imagine they'll need to be updated for Synergy 2).

Thanks Nick!

Link to post
Share on other sites

Got it.

The ip address Synergy is attempting to connect to, 165.227.28.181 in this case, is being treated as a newly observed domain and therefore blocked out of caution.  Once I forced it to a category of remote access problem is solved.

Link to post
Share on other sites
  • Synergy Team
Nick Bolton
1 hour ago, Canterrain said:

Got it.

The ip address Synergy is attempting to connect to, 165.227.28.181 in this case, is being treated as a newly observed domain and therefore blocked out of caution.  Once I forced it to a category of remote access problem is solved.

Aha! Excellent work. Yeah, we figured it may play havoc with corporate firewalls.

Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...