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.