Trouble setting up a private Discovery and Relay Server

pyromanci · December 17, 2015, 9:08pm

Hello,

I recently stumbled on to Syncthing. It looked promising and would suit a need I’ve been try to fill here at our main office, branch offices, and mobile users.

So I played with it using the public relays and discovery servers. Everything worked fine. Stuff was syncing without issues. I then switch to a private relay (v0.12.4) and default discovery server. Again everything worked well and things were staying synced.

Then I switched to both private relay (v0.12.4) and discovery(v0.12.2) servers. Syncing then stopped working. I restart the syncthing’s, relay servers, and discovery servers. I then made sure each syncthing’s were pointed pointed to the same addresses for discovery and relay server.

I do see this in both the web interfaces:

Discovery   3/3
Relays      1/1

So sync thing is connected to them, but they are not connecting to each other. Randomly out of no where I do see this appear in the discover debug log:

GET /?device=(id1)
GET /?device=(id1)
Stats: 0.00 announces/s, 0.01 queries/s, 0.01 answers/s, 0.00 errors/s

Then followed by the 2 machines connecting and syncing. with this in the relay log:

2015/12/17 15:58:40 listener.go:46: Listener accepted connection from 127.0.0.1:48766 tls true
2015/12/17 15:58:40 listener.go:105: Message protocol.ConnectRequest from (id2)
2015/12/17 15:58:40 session.go:53: New session <184dd/b5b0c>
2015/12/17 15:58:40 listener.go:161: Sent invitation from (id2) to (id1)
2015/12/17 15:58:40 session.go:121: Session <184dd/b5b0c> serving
2015/12/17 15:58:40 listener.go:236: Sending message protocol.SessionInvitation to (id1)
2015/12/17 15:58:40 listener.go:187: Closing connection (id2): xdr read: read tcp 127.0.0.1:48766: use of closed network connection
2015/12/17 15:58:40 listener.go:46: Listener accepted connection from 127.0.0.1:48767 tls false
2015/12/17 15:58:40 listener.go:265: 127.0.0.1:48767 session lookup <184dd/b5b0c> 184dd
2015/12/17 15:58:40 session.go:106: New connection for <184dd/b5b0c> from 127.0.0.1:48767
2015/12/17 15:58:40 listener.go:46: Listener accepted connection from *.*.*.*:43410 tls false
2015/12/17 15:58:40 listener.go:265: *.*.*.*:43410 session lookup <184dd/b5b0c> b5b0c
2015/12/17 15:58:40 session.go:106: New connection for <184dd/b5b0c> from *.*.*.*:43410
2015/12/17 15:58:40 session.go:138: Session <184dd/b5b0c> starting between 127.0.0.1:48767 and *.*.*.*:43410
2015/12/17 15:58:40 session.go:237: Proxy 127.0.0.1:48767 -> *.*.*.*:43410

Then the syncing stops with this showing in the relay log.

2015/12/17 15:59:12 session.go:163: Session <184dd/b5b0c> ended, outcomes: write tcp *.*.*.*:43410: broken pipe and read tcp *.*.*.*:43410: connection reset by peer
2015/12/17 15:59:12 session.go:199: Session <184dd/b5b0c> stopping
2015/12/17 15:59:29 listener.go:105: Message protocol.Pong from (id1)
2015/12/17 15:59:33 listener.go:105: Message protocol.Pong from (id1)

Now I don’t know if it’s a config problem or not. If your wondering here are the comandlines i’m using:

/var/sync/discosrv -listen=0.0.0.0:8470 -key=/var/sync/key_discover.pem -cert=/var/sync/cert_discover.pem -debug=true
/var/sync/relaysrv -pools="" -listen=0.0.0.0:22067 -keys=/var/sync/ -status-srv=0.0.0.0:22070

The reason for the private relay and discovery is for the firewall bypass and that some of the devices we need to sync go behind heavy firewalled and filtered connections. That I can not just open domains to be allowed. Since we do not own/control that hardware.

So any help or advice would be great.

AudriusButkevicius · December 17, 2015, 9:57pm

You can’t run discovery on the same node as the peer, as the advertised address becomes 127.0.0.1. You can’t even run it in LAN, as the address will be a LAN address which might make no sense out on the internet.

As to the relay, it’s not clear why the devices decide to disconnect, device logs would be more useful in that case.

pyromanci · December 18, 2015, 2:15am

Ok, it seem the problems were the discover server and syncthing running on the same machine. Which I think should be added to the documentation for the Discover Server.

I’m wondering though, I do have 1 node I would want this setup on. That node does happen to have multiple public IP’s. Could I tell each component to run only on one of the IP’s and have them play nicely together?

AudriusButkevicius · December 18, 2015, 2:29am

Not sure, but probably not, as the kernels are usually clever enough to route it internally, and the address will still be 127.0.0.1.

If you have static addresses beforehand, why do you even need discovery? You can just use specific addresses for each device?

pyromanci · December 18, 2015, 2:37am

Not all the nodes I am wanting to use Syncthing with have statics. Only this 1 server does.

I will try assigning an IP to each and see what happens.

kluppy · December 18, 2015, 7:30am

Then use dynamic for the rest of the nodes and use static when you add the discover node. The IP of that node will not change or if it does the discovery will be broken.

pyromanci · December 18, 2015, 1:35pm

Giving the discovery server, relay server, and syncthing there own IP’s on that machine did in fact allow me to run all 3 on the same machine.

JinxGenius · December 19, 2015, 2:51am

I run syncthing and discovery server on the same PC, it DO works, however, if you do have static IP, please do insert the field, it’s more promising that way.

the only thing matter is not running into the same port.

system · January 18, 2016, 2:51am

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.