Failed to get cluster leader candidate - Windows and Linux pairing.

[Polisson]

Bug/Issue

Can't establish Virtual Switch connection.
My setup consist of two devices, Linux and Windows.
If started pairing, both machines show popup so I'm assuming discovery port is working.

Generally I've red FAQ section about issues.

1. Checked firewall on Windows and set Inbound holes (any port, both protocols)
2. Disabled firewall on Linux completely
3. Tried other ports 4450, 1950

Logs
Timestamp: 2024-03-19T11:50:05.638Z
Cursr_app_Win.log
Cursr_app_Linux.log

Environment

• OS details: Windows 10 x64 22H2 and KDE neon 6.0 (Graphics Platform: X11)
• Cursr Version: 1.6.6
• License: Free

Additional Context

My Windows machine is a corporate workstation with restricted admin abilities. Windows firewall could be set, but maybe other security solutions block functionality, but is out of my control.

[ragauskl]

From logs looks like they do communicate, there's likely a timing issue. Next release 1.7 has a fix to one of timing issues that I managed to reproduce myself, it may be related so if you can wait for 1.7 (that I should be releasing at some point next week or so) and see if that resolves the issue, if not then let me know and I'll look into this again

[ragauskl]

1.7 is now available in pre-release mode, to allow update to pre-release you'll need to enable 'Early Access' mode in 'General' settings and 'check for updates' in 'About' settings section.

Alternatively you can wait for 1.7 to be released in stable mode as soon as some users test it and I make sure it's stable.

[ragauskl]

Fix now available in stable release 1.7, if no further comments are made on the issue in next 2-3 week I'll close it as complete

[Polisson]

Thanks for being patient. Unfortunately, nothing changed for me after upgrading to v. 1.7.
I've tested now again on 1.7.1, but the issue occurs still.
Attaching fresh logs from both machines - timestamp of trying to connect is e.g. 2024-05-08T06:46:10
Linux_app.log
Win_app5.log

[Polisson]

I've just done some additional testing: obtained a third machine, this time Intel MacBook with (w macOS Catalina) and successfully connected to my Linux station. When trying to use Connect button from Windows PC, Scanning is started but at the end previously linked Mac and Linux disconnect. Then I can start connection from Linux and all three machines shows discovering, but only Mac becomes connected or connecting is unsuccessful.
So the culprit exists in Windows machine.

[ragauskl]

I see... thanks for the information, I will have a look into the logs and see what I can find. Next two weeks will be very busy for me so it may take some time before I can have a proper look at this but I will try and include a fix for the next patch 1.7.2

[Polisson]

I've just done some additional testing: obtained a third machine, this time Intel MacBook with (w macOS Catalina) and successfully connected to my Linux station. When trying to use Connect button from Windows PC, Scanning is started but at the end previously linked Mac and Linux disconnect. Then I can start connection from Linux and all three machines shows discovering, but only Mac becomes connected or connecting is unsuccessful.
So the culprit exists in Windows machine.

[joerohde]

Windows Firewall - try adding an exception for cursr.exe.

Seems to be able to broadcast/listen for discovering, but not bind the connection port. After adding an exception it worked fine (for me).

[ragauskl]

I've recently had a similar issues due to getting connected to a network that previously used to be marked as 'Private', but this time it was set to 'Public' for some reason, changing it back to Private (as it was home network) resolved the issue as by default settings Cursr communications should be allowed on Private networks (unless you've selected otherwise or have other default settings).

It's a similar solution as @joerohde mentioned, but I would suggest to be careful about adding exceptions if it's on Public network.

I've added correction to Cursr FAQ section but haven't published it yet:

Make sure there are no Inbound Firewall rules blocking 'UDP' or 'TCP' for 'cursr.exe' or 'Cursr'. By default these should be allowed on Private networks unless you chose otherwise, therefore check if your network is set to Private or Public and then check corresponding firewall settings. Alternatively to avoid unnecessarily looking for individual firewall rules you can also disable firewall (not recommended on Public network) to check if it will help, before tracking down individual rules causing the issue

[ragauskl]

@Polisson Have you had a chance to see if it was a firewall issue? I'm going over issues every now and then and wanted to see if this is still something I need to continue looking into or if the issue can be closed.

[Polisson]

Yes, I've checked my firewall, (set ports rules to allow any traffic and have them till now). Updates of Cursr changed nothing.
Also, maybe it is caused by other firewallish mechanism, which isn't under my control (as I mentioned: corporate machine). My Windows firewall has a holes, but in OS there is also installed SentinelOne Agent which potentially could have separate traffic analyzing.