Timeout when gathering relay candidates
Hey,
I've been using Wayk Now successfully for a couple of months now but since around 2 weeks ago (8th of May), I have not been able to connect to my host workstation anymore. The client is on Windows 10, the host is on Ubuntu 18.04 and located behind firewalls.
I saw in the logging that, when trying to start the session, the host contacts the Jet Relay server to gather the relay candidates but this seems to time out every time since the 8th of May. This used to work prior to that. I don't know if this is related to a firewall change or the Jet relay server itself.
This is a snippet from the NowService.log on the host machine:
2020-05-27 09:23:29 common::logging [INFO] - << HTTP Response
2020-05-27 09:23:29 common::logging [DEBUG] - Http message (callId=7) succeeded in 141 ms
2020-05-27 09:23:29 common::logging [DEBUG] - GatherRelays: {"id":"a3c013d7-b7f5-46bb-977b-9a949a4a1792","relays":[{"url":"https://api.jet-relay.net"}]}
2020-05-27 09:23:29 common::logging [DEBUG] - GatherHosts: {"id":"a3c013d7-b7f5-46bb-977b-9a949a4a1792","candidates":[{"id":"7692904a-f496-9683-af84-74d3edf29783","url":"tcp://10.65.10.105:4489"},{"id":"b364afa8-3fe0-50e2-c0d9-bf2023c4f927","url":"tcp://172.17.0.1:4489"}]}
2020-05-27 09:23:34 wayk_rust::jet::association [DEBUG] - gather_relay_candidates for https://api.jet-relay.net/jet/association/a3c013d7-b7f5-46bb-977b-9a949a4a1792/candidates: Transfer error [28] Timeout was reached
2020-05-27 09:23:34 common::logging [WARN] - Failed to gather relay candidates from {"id":"a3c013d7-b7f5-46bb-977b-9a949a4a1792","relays":[{"url":"https://api.jet-relay.net"}]}
All Comments (3)
Hi,
Can you try loading https://api.jet-relay.net/health in a browser from the Ubuntu 18.04 host, and see if you can access it? It should return a simple string that says the service is healthy. We have recently switched our jet relay servers from Azure Container Instances to managed virtual machines in Azure, so the IP addresses behind api.jet-relay.net have changed. Since api.jet-relay.net is DNS load balanced and points to one of many geo-redundant jet relay server instances, the IP addresses are subject to change already, so I don't think it should have made a difference.
Can you tell me more about how the firewall on Ubuntu 18.04 is configured? If you told me that this happens once in a while, I would have been tempted to say the issue is with the service, but you're telling me this happens all the time. It could still be an issue with our relay servers, but in this case, it would mean that your Ubuntu 18.04 server is located near one relay server that always fails. We can still take a look into it, we'd just need to know which one you're getting from the Ubuntu 18.04 server, you can figure out by doing "ping api.jet-relay.net" and posting the resulting server here.
Best regards,
Marc-André Moreau
Hey, thanks for the response.
I am unable to load https://api.jet-relay.net/health from the host. It does work from the client side though. I also checked and both host and client and they are getting connected to the same relay server: jet-0-10-9-prd-weu-1.jet-relay.net (52.166.95.181).
I guess this means that the issue seems to be on the host's side. Unfortunately I can't tell you anything about the firewall configuration as this is beyond my control.
Best regards
Hello
Thanks for the feedback. Unfortunately, there's not much more we can do in this case: if a direct route between the client and server is not possible, a Jet server needs to be involved. The best would be if the firewall on the host could whitelist *.jet-relay.net.
Thanks and kind regards,
Richard Markievicz