The connection could not be established

UPDATE: Problem is related with f-secure computer protection... idk jet why, but I did install wayknow at few computers more and at every one the same problem...
When I turned off this firewall wayknow start working... I'll give you update when I find whats going on.

Hi Kris,

I'm glad you found the source of the problem, but yes, please give us an update once you figure out what is going on between Wayk Now and f-secure computer protection. I assume it got blocked automatically by the firewall, and we only add a Windows Firewall exception when installing with the .msi.

Best regards,

Hello,

I didn't have time for tests, but idk if it's only firewall problem - wayknow client (client site) was ready for connection, green dot and looks normally.
From remote machine I get very quick window popup with info "The connection could not be established" and nothing happen.
When I check logs it was info about certificate problem or smth like that.

I'll have possibility log in tomorrow, I'll check and back here.

Hello

Did you have any update on this? From our side, we did a test with a trial version of FSecure Computer Protection, installed Wayk Now, and were able to connect as normal. So perhaps there is something else interfering here or a difference in configuration. As always, log files will be helpful.

Thanks and kind regards,

Hello,

no I didin't have more access at customer computer and was little bit busy so didn't have time for additional test.
I'll do smth for him next week so I'll have possibility check whats going on.

Richard I included logs at first post. As soon when I get access at customer computer I grab some logs for you. Not too much, but didn't have time for more.
Customer run wayknow.exe client at his computer, that's why I called wayk_client_exe.log

--
KriS

Hi Kris

Thanks - I hadn't noticed the logs included in the first post.

The log shows the connection successfully to Wayk Den, but no incoming connection attempt. Either:

• The service was installed and handled the connection
• The log wasn't running when you tried to connect
• Something stopped the connection from reaching either the machine, or Wayk Now

Since I know that you understand well how Wayk Now works, I don't think it was the first two reasons. From my side, I did try again with FSecure installed and was able to successfully connect. The one strange thing I notice that is in both your log and my log, is the first line:

> [WARN][com.winpr.file] - Unsupported file mode 65535 for _wchmod

I haven't seen it before. From examining the code and where it occurs in the log, the error does seem benign but it also indicates something else might be going on.

Do you still have your local client log from when you tried to connect to that customer? It may tell us something more. Otherwise, if you work with that customer again this week please try to grab your local client log as well. You can send to me via a PM or at wayk@devolutions.net.

Thanks and kind regards,

Hello,

logs from first post was _only_ from wayknow.exe file client running at customer computer.. I didn't have installed msi version jet... I did it later, but didn't have possibility grab service log files, because I can't log in :)

Few more this that I didn't mentioned before:

• with running exe wayknow client, when customer gave me source ID, I use "ask for permission", he confirm popup window, but at my site, I get error (I don't remember what)
• I wasn't able connect with valid source ID/password provided by user
• at next day I installed msi version, make new local account with admin rights and still can't connect via wayknow service even when I provided valid username/password.

--
KriS

Hello,

small update... Today I did have chance download log files wayknow service from computer which I mention at first post.

When I run wayknow today it was version 2020.1.5 - so I updated at 2020.1.7 and when I try connect I was able do it.
I don't remember if I change somethings 3 weeks ago or why it's starts working today.
I didn't have possibility do any test, so I can upload only logs.

--
KriS

Hi Kris

Thanks for the updated information.

Taking a look at the logs, it seems the server may have (or had) a networking issue - it could be related to F-Secure, software, hardware, maybe just a glitch? Without knowing more about the environment it's hard to make a judgement.

Two things make me suspect this:

First, when Wayk starts up, it waits with a delay to find network interfaces. If it takes more than 100ms to find interfaces, we log a message and that can be seen twice on the day you experienced the issue originally (5th May):

2020-05-05 12:36:18 common::logging [DEBUG] - NowServer_WaitForNetwork: 3437 ms

It's pretty irregular for that to take such a long time, even if the service is coming up with the system (i.e. after a reboot).

Second, the log is littered with:

2020-05-07 07:00:12 common::logging [DEBUG] - mbedtls_ssl_read: 0x0050
2020-05-07 07:00:12 common::logging [DEBUG] - mbedtls_ssl_write: 0x0050

It shows we lost connectivity, because the underlying TCP connection was dropped. Normally that happens at the network level, and I would estimate there's at least 40 disconnections in the service log file (that can be that Wayk Den is reporting a connection drop even when no-one is using the machine).

Both those things really point to the machine having a networking issue, and it's possible you just got "lucky" with your connection today.

Wayk Now 2020.2.0 (should be released by the end of this week) slightly relaxes our TCP keep-alive settings and it's possible this will help (it will take a little longer for a dropped network connection to interrupt Wayk connectivity). It also allows tuning the TCP keep-alive settings so that's also something we could explore. The issue may also turn out to be transient. When we've seen something similar before, it was attributed to a bad switch on the network, and when the switch got replaced the problem suddenly went away.

Let us know if the problem persists, and if you were able to successfully use other remote access software on this server. I will say it's also likely that we have more work to do in tuning how we time out our connections based on what the underlying network is doing (there's a balance to be struck there between responsiveness and robustness).

Thanks and kind regards,