Preliminary Troubleshooting

[Kelvin Tran 142]

This applies to Synergy 1 and Synergy 2 users.

Alongside any other troubleshooting guides or examples that Symless gives you, please follow these troubleshooting steps as they'll save time for the community members and help give those members a foundation in order to help you.

1.) Restart Synergy - I can't tell you how many times a simple restart of the Synergy process will help. If it's Synergy 2, end it through Task Manager or Activity Monitor (on macOS). On Linux, the different distros may make the termination process different (plus, I haven't used Linux in years and don't plan to), so check for your specific distribution of Linux. 

2.) Restart your computer - If restarting Synergy doesn't help, restart your computer as this will perform a flush of cache (in RAM) and services. It will also reestablish your DHCP lease and IP address, critical if you want Synergy to work.

3.) Make sure your IP address is correct. - Because I've copy-pasted this for Synergy 1 from Synergy 2, I will cover both of the versions for this topic. If you are still on Synergy 1, check if auto-configuration for your client is on. If it is, turn it off and go to your server. If you are on Windows, press Windows key + R and type in "cmd" (w/out quotes). You'll get the command prompt window. Type in "ipconfig" and hit enter. Find your network card and the IP address associated. Ensure that it is not an APIPA (Automatic Private IP Addressing), or zeroconf self-config IP (APIPA from Microsoft is the 169.254.x.x subnet) address. If it's not, go ahead and enter the IP address into the IP config field for Synergy. If you're on Mac, go to a terminal of some form and use ifconfig. Look for either eth0 or wlan0 (ethernet and wireless) and your IP address should be listed under that. It will not always be eth0 and wlan0, but most times, if you don't have more than one of each, your main will be 0. But, if you run virtualization software, you will easily have more than 1 network card listed (for your virtual NICs) and you will have to confirm. If auto-config is off, check for typos or IP address changes and if that doesn't work out, switch auto-config back on.

4.) Firewall and Security Settings - If your server process cannot communicate out or if your client process cannot communicate with your server, it is possible that your firewall, security settings/policies, or other security solutions may be blocking Synergy's communications. Try disabling those security solutions and firewalls or setting them to allow all incoming communications that's addressed for your system. If this turns out to be your problem, save yourself the time that you'll take to post! Go back to your security solution/firewall or group policy and add the Synergy executable to the whitelist of processes. Please be aware that in a business, you may need to escalate up to a system/network administrator in order to have them change their group policy/network security software to have it allow Synergy communications. As @IT Troll (moderator) pointed out, there are two ways you can accomplish a "firewall exception" as it is called in technical terms.

• The first way is to allow these 4 programs in the Windows Firewall: "

  %ProgramFiles%\Synergy\synergys.exe

  %ProgramFiles%\Synergy\synergyd.exe

  %ProgramFiles%\Synergy\synergyc.exe

  %ProgramFiles%\Synergy\synergy2.exe" (credit to @KringleKrebs and @Ilya for finding these executables). Please note that synergy2.exe only pertains to Synergy 2.

  • If you are interested, %ProgramFiles% is the Windows alias to the user's program files folder instead of looking at the drive letters and all of that. Did I mention that what I'm saying here is primarily geared towards Windows (Windows Firewall)? 

• The second way (this will be useful to you if you are using network-perimeter based or HIDS/HIPS software) would be to manually exclude ports 24800, 24810, 24888, and 8081 (credit to @IT Troll). Note that 24800 and 24810 can be changed within Synergy 1 configuration (and presumably soon for Synergy 2 as well) and you will have to add the exception for that if you go that route. I find opening doors directly to be much more effective at guaranteeing it works, as opposed to placing a guard at the door and checking the IDs of each program that tries to use it (which I have seen fail spectacularly before).

5.) Reinstall Synergy - Completely uninstall all files from your system that pertain to Synergy and do a clean reinstallation. This may help to repair corrupted files and core processes that are failing to start on your system. 

6.) Check if this issue is a known bug - If all of the steps listed above did not work, check the forums to see if the issue you're having is a known bug. If it is, just know that Symless and @Nick Bolton's team are working on it and will release an update that fixes the issue. You will have to wait, unfortunately.

If you have attempted all the steps above and cannot get everything working (and it isn't a known bug), go ahead and post on the forums! The community will help you to pursue a resolution to the issue that you're having. Just go ahead and mention this post so that the people helping you will know what troubleshooting steps you've tried. List your FULL logs (not some screenshot) and additional troubleshooting steps you have attempted besides these. Let us know through your post what version of Synergy you're running, server and client hardware information, what operating systems you're running on the client and the server, and other information that may be helpful. Please note that on Synergy 2, you have options to send your full log through a link that will improve the readability of your logs, since they have the tendency to be extremely long.

Additionally, Symless has tech support! If you'd like to try tech support (officially) first, you can contact [email protected] and work with them before you come here if you'd like.

If you are completely unsatisfied with your purchase, Symless is happy to offer a refund through [email protected] 

Happy productivity!

Edited October 19, 2017 by Kelvin Tran

[jaap aarts 65]

to stop the restart on linux close it like any other application.

if you have the service open in a terminal(using the terminal to manually start it) press ctrl-c, this will close the service.

if you have a modified(working) service then restart it using the terminal:

systemctl restart synergy

 

[Kelvin Tran 142]

3 hours ago, jaap aarts said:

to stop the restart on linux close it like any other application.

if you have the service open in a terminal(using the terminal to manually start it) press ctrl-c, this will close the service.

if you have a modified(working) service then restart it using the terminal:

systemctl restart synergy

 

Yeah, what he said! 

[GranPaSmurf 108]

WINDOWS FIREWALL 

These Windows 10 firewall settings have worked for several users first by Ilya reported on the forum:

manually add the following rules to the windows firewall:

%ProgramFiles%\Synergy\synergys.exe

%ProgramFiles%\Synergy\synergyd.exe

%ProgramFiles%\Synergy\synergyc.exe

%ProgramFiles%\Synergy\synergy2.exe

 

permit synergys.exe to "Outbound Rules" (Domain + Private) in Windows 10

added port 24810 inbound and outbound rules to windows firewall on both systems

[IT Troll 20]

I posted about this back in September when beta4 was first released. But that will have dropped down the thread list now.

IMO, adding program exceptions (using the four paths listed above) is a better solution than port exceptions. With program exceptions you are permitting that specific program only and by default you are permitting it to use any port(s) it wants. So if the port changes for any reason, your rule will still work as expected.

With port exceptions, by default, you are allowing any program to use that specific port. So some other unexpected/unwanted application could make use of the port.

You don't need to do both.

Also, with a standard Windows Firewall setup, you only need to add inbound rules, it is not necessary to add outbound rules. By default any program on your computer can connect outbound. You will only need to add outbound rules if you are using some third-party firewall manager which denies outbound by default.

[Kelvin Tran 142]

On 10/16/2017 at 4:05 AM, IT Troll said:

I posted about this back in September when beta4 was first released. But that will have dropped down the thread list now.

IMO, adding program exceptions (using the four paths listed above) is a better solution than port exceptions. With program exceptions you are permitting that specific program only and by default you are permitting it to use any port(s) it wants. So if the port changes for any reason, your rule will still work as expected.

With port exceptions, by default, you are allowing any program to use that specific port. So some other unexpected/unwanted application could make use of the port.

You don't need to do both.

Also, with a standard Windows Firewall setup, you only need to add inbound rules, it is not necessary to add outbound rules. By default any program on your computer can connect outbound. You will only need to add outbound rules if you are using some third-party firewall manager which denies outbound by default.

What you're saying is true about the program exceptions, but I prefer port exceptions because whilst it's true that a program can then come and use that port if they'd like, from my understanding, no two ports can be used simultaneously by two different programs and port exceptions work better with router-based firewalls, since I know that there will be situations where that will matter. For a host-based firewall/IDS/IPS, what you're saying is ABSOLUTELY true. 

I'd like to agree to disagree with your assertion that there is not a desire to do both. Doing both is overkill, but it is a way to ABSOLUTELY guarantee it works. I've seen some of these cases with other applications where it will not work with a program exception but then go ahead and work again with a port exception or if I turn the entire domain into a DMZ. It is overkill, but it's a way to ensure that it works.

With a standard Windows Firewall setup, it's true. However, see note 1 about guaranteeing that it will work.

[IT Troll 20]

My post was specifically aimed at Synergy 2, which does not work out of the box with the Windows host firewall.

Port-based rules are indeed better suited to dedicated firewall appliances, but that is not what we are talking about here. I can't see anyone trying to control devices with Synergy which are sitting either side of a network perimeter firewall.

Setting both port and program exceptions is overkill and unnecessary for Synergy. Setting the program exception alone will also absolutely guarantee it works. However, the same is not true of just setting the port exception as the port might change in a future release, if unavailable, or through a custom configuration.

From a general security strategy point of view, you should avoid overlapping rules which weaken your defence any more than is absolutely necessary. Having said that, setting both is still vastly better than just disabling the firewall completely which the official troubleshooting guide still advocates.

[IT Troll 20]

Just to tighten up on this a little more. It would seem that on both Windows and Mac the device-to-device communication occurs on ports 24800 and 24810 which is used by the synergyd, synergys and synergyc processes. Port 24888 is also used but it appears just for local loop back purposes.

Synergy2 (the GUI) just appears to use https to connect to Symless and also the local loop back.

synergyd also makes an external connection to Symless on port 8081.

[Kelvin Tran 142]

Sure, you could do that, and I will edit the post. But I still stand by the fact that I prefer port based exceptions personally. I've seen program-based exceptions fail spectacularly in cases that don't necessarily pertain to Synergy. I will edit the post and give you credit for your contribution.

[Ilya 1]

I just want to make it known that it wasn't I who initially found that adding firewall exceptions for the exe's fixed many peoples' issues, but it was actually @gee4vee. Then, @Fridgey pasted the actual paths to the executables that he allowed through his firewall. Lastly, @caveguy shared that he also added the port to the firewall. The combination of all three of these users and their suggestions is what got my setup working...so THEY deserve the credit, not I.

[Dread Pirate Wolf 1]

I posted this for people that are having issue with Windows 7 64 Bit and Synergy2

 

[Keiichi25 2]

Suffice it to say, the next beta build installer will need to address the firewall assignments to Windows based computers to either:

a) place the programs needed to firewall allows

b) specify range that should be open port wise.

While this may not cover the third party firewall solutions, another suggestion would be to include in the synergy2 gui a help button for people who don't visit the forums to have an alternative means to see where or what they might want to try.

[SilverbackSays 0]

On 18/10/2017 at 10:33 AM, IT Troll said:

Just to tighten up on this a little more. It would seem that on both Windows and Mac the device-to-device communication occurs on ports 24800 and 24810 which is used by the synergyd, synergys and synergyc processes. Port 24888 is also used but it appears just for local loop back purposes.

Synergy2 (the GUI) just appears to use https to connect to Symless and also the local loop back.

synergyd also makes an external connection to Symless on port 8081.

Cheers @IT Troll, this fixed the issue I was having for me.

 

I run ESET Endpoint Security, and I had to create a rule for synergyd.exe, synergyc.exe, and synergys.exe, allowing bidirectional access on TCP ports 24800, 24810, and 24888, to get beta4 to work. 

 

Beta is beta, of course, but it's a real pain in the rear to have to make these manual changes. Let's hope the release version does something to make this easier for those without the skills or forethought to check these forums

[IT Troll 20]

20 hours ago, SilverbackSays said:

Beta is beta, of course, but it's a real pain in the rear to have to make these manual changes. Let's hope the release version does something to make this easier for those without the skills or forethought to check these forums

It is entirely possible to add standard Windows firewall rules during the installation process. I think this just got missed due to the changes introduced with beta4.

However, there are a multitude of third-party "default deny" security products out there which may require additional configuration. These will require very clear guidance if non-technical users are to stand any chance.

[Merlinfrombelgium 0]

I can confirm Synergy 2 beta 4 working, after adding 4 program rules from OP step 4 to Windows Firewall for inbound connections and one outbound rule for synergys.exe. Running Windows 10 1709 on both ends. I think it actually worked after adding the inbound rules on my server system (the one with kb and mouse) and having only the outbound synergys.exe rule and the predefined "Synergy" and "Synergy 2.0" inbound rules on the other system. The mouse movement on the client side is very choppy though.

Looking forward to try beta 5!

[Nick Bolton 400]

Finally, Synergy 2 beta5 is here!

Get the latest version: Synergy-v2.0.0-beta5

[IT Troll 20]

Nick has unpinned and unfeatured this post because much of is it now incorrect following the release of beta5.

Prior to installation of beta5, I removed all my manual firewall rules and let the installer do it's thing. I'm happy to report that it added the required rule and connections were made without needing any intervention.

The binaries have been renamed to; synergy-config (the GUI), synergy-core, and synergy-service.

synergy-config connects to the Symless cloud server using standard https and so should no longer be a problem for most perimeter/boundary firewalls.

The installer automatically adds a rule to the Windows firewall for synergy-service, all the host-to-host communications are now handled by this process; it uses a number of different ports.

If you use a third party host firewall and need to add a rule manually, then just adding the following as a program exception should be enough.

%ProgramFiles%\Synergy\synergy-service.exe

Edited October 31, 2017 by IT Troll

[Nick Bolton 400]

13 minutes ago, IT Troll said:

Nick has unpinned and unfeatured this post because much of is it now incorrect following the release of beta5.

 

Feel free to update and re-pin