Error in connecting to relay server


(Cn Mayank) #1

I launched a private relay server(inside a container) and configured two Syncthing instance to use it via static relay address. Syncthing instance could connect to(i.e. register) with the relay server (see point 1 below) but for transferring data the devices remained in disconnected state with the connection issue shown in point 2.

  1. listener.go:117: Message protocol.JoinRelayRequest from DWG7AF6-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX listener.go:117: Message protocol.Pong from DWG7AF6-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX

  2. structs.go:191: DEBUG: dialing DWG7AF6-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX relay://tcp.ey.devfactory.com:10126/?id=Z3W3VFC-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX&pingInterval=1m0s&networkTimeout=2m0s&sessionLimitBps=0&globalLimitBps=0&statusAddr=:22070&providedBy=codenation error: dial tcp 10.231.128.24:22067: connect: connection refused

I believe it should have tried to connect to 10.231.128.24:10126 as specified in the url in log(relay://tcp.ey.devfactory.com:10126), but it is trying to connect to 10.231.128.24:22067

I am using syncthing version 0.14.38 and syncthing relay version is also 0.14.38. I checked if there is any configuration issue on my end but could not figure it out yet.


(Jakob Borg) #2

Port 22067 isn’t hard coded anywhere in Syncthing itself, so it should not be making it up. Note though that device A will be connecting to the relay address announced by device B, which is the relay address that B is connected to. This may be different from the relay address A is connected to.

So - how is DWG7AF6 connected to the relay? Port 22067 or port 10126?


(Cn Mayank) #3

Hovering over the addresses shown, pops a small “Discovered” message.


(Jakob Borg) #4

So lots of addresses announced on various ports. NAT mappings? I have no idea.


(Cn Mayank) #5

Ok, like I said i am launching the relay server inside a container and this container is launched on a deployment platform(like heroku) and the same platform is making the exposed port accessible via “tcp.ey.devfactory.com:10126” and so on. I have requested them for more information on how they are doing port mapping if it might help.

But seems relay server is not supposed to be used via a container behind some port mapper, and launching the relay service on a dedicated instance would definitely work.

Thanks


(Audrius Butkevicius) #6

It should work fine in a container if you set it up correctly.


(Cn Mayank) #7

Just to help anyone who may want to deploy relay server on a hosting platform I was able to resolve it by ensuring that the -listen parameter in the syncthing relay was set to the same port number which my deployment platform was exposing.

For e.g. if port exposed in your container is gonna be assigned a url:port by the hosting platform to be externally reachable(in my case when i want to expose port xx of my container, it was reachable at tcp.ey.devfactory.com:10126) , i set -listen option to 10126. Due to this the syncthing peers started dialing correctly at ip:10126 instead of ip:22067

i believe deploying relay server on a general purpose cloud hosting platform is acceptable for testing/experimenting but perhaps it would be better to run relay servers on high network performance instances on say AWS. (can anyone comment which aws instance type would be recommended for running relay server, m5.large maybe? )

Also is the source code for https://relays.syncthing.net/ is also open source ?

Thanks


(Jakob Borg) #8

Yes, the source for the relay pool server is in the main repo: https://github.com/syncthing/syncthing/tree/master/cmd/strelaypoolsrv

(No opinion on the sizing; I think a small VM should do fine.)


(Jakob Borg) #9

Thanks for reporting back with the solution/result!


(Audrius Butkevicius) #10

You can pribably run a relay on a rasberrypi and it will perform comparably to the largest instance on aws. Relay server doesn’t do much in general.


(Antony Male) #11

They do need a reasonable amount of memory, and lots of network bandwidth, in my experience.


(Jakob Borg) #12

Bandwidth clearly. I honestly don’t know… I’ll run one and check. There’ll be some network buffers per connection eating some RAM…


(Audrius Butkevicius) #13

We barely have 1Gbit rate across all relays, so I don’t think having much bandwidth is a prerequisite as either everyone runs on low bandwidth, or the implementation is slow, or people don’t need that much bandwidth as we never fill the pipe. I think most relays are sub 10Mbit, which is probably what sdsl would give you. There is no encryption so it should not use much cpu. I think we have 4Mb buffer per client, so for an average of 1000 active sessions you’d need 4gb of ram, which is still in theory rpi territory.


(Jakob Borg) #14

So I set one up in Johannesburg, there was a distinct lack of relays on the African continent and there are at least a few users who could benefit from it. Will use it for testing and to monitor how it behaves under load, if there is enough use to cause load.