Syncthing relay TCP connections

Feature
1

Hello. How many TCP connections does the relay need to establish for each client in order for the relay to work?

2

1.5, on average.

3

I’m not very knowledgeable about networking stuff, why is there a fraction in that answer? Is there randomness? Why? Also, should the relay in principle work if there is only one established TCP connection between a client and the relay? I thank you for your knowledge and time.

4

One data connection and, for the listening side, one control connection.

What’s the background for the question, though?

5

I couldn’t make the relay work on campus.

A few days ago I decided to roll a private relay. From my limited observations, I guess that when a client (A) connection is established with the relay a control channel is established. If there are no other clients on the relay to talk to that’s the only connection.

As soon as another client (B) (where sharing has been configured) connects to the relay, I am guessing a couple of things happen TCP-wise, in no particular order:

  1. a control channel is made with B
  2. a data channel is made with A
  3. a data channel is made with B

The relay then does its thing.

The problem I think, is that on campus the control channels appear if I remember right. But no other channels are established. The clients don’t see each other. I think this is why the relay won’t work and the reason for my questions. I guess no additional ports can be opened on the ip address.

When I switch the network from using campus services to my phone hotspot, the relay works again and I see four connections established. The clients see each other.

1 Like
6

Relaying has two sides: The control connection when a host has included the relay server in its “Sync Protocol Listen Addresses” configuration. By default that includes the public relay pool, you must have configured your custom relay there.

Then there’s the part where a node’s listening state on a relay is discovered by another, which then tries to contact the relay server for the feed-through data connection. This discovery either needs to be specified explicitly by adding the relay server under the remote’s “Device Addresses” field. Or it is discovered through the regular global discovery mechanism.

It could be that on your campus network, discovery is not working properly. Thus the second part fails and it starts working when you connect through the hotspot where discovery connections are not filtered. Just a guess though. You should look under Listener Status and Discovery Status in the web GUI to see what’s going on. Debug logging could also give more insights (discovery and relay facilities mainly).

2 Likes
7

Before the expts carried out below, the addresses field of the remote client was set to “dynamic” and I have turned off global discovery. The relay only worked when I used my phone hotspot.

Following acolomb’s post, I’ve managed to make the relay work. Thank you.

Expt 1:

At first I set the addresseses field to tcp://111.111.111.111:443 because in the GUI it says ‘Enter comma separated (“tcp://ip:port”, “tcp://host:port”) addresses or “dynamic” to perform automatic discovery of the address.’ (That’s a completely made up IP btw :p)

Messages seen on GUI (in red) under address prop:

  • no application protocol
  • EOF

(I let it run a bit and these messages appear to cycle. Looks related to networking.)

Messages on terminal server-side (debug):

  • Listener failed to accept: failed to identify socket type (listener.go: 46)

    (consequence of err from line 37: conn, isTLS, err := listener.AcceptNoWrapTLS())

Expt 2:

I ignored the GUI advice and instead set it to relay://111.111.111.111.:443. I guess this changes the protocol to ‘relay’ from ‘tcp’.


 and it works. GUI reports connection type as ‘Relay WAN’.

Looks like data transfers are handled by session.go and listener.go is checking to see if the link is alive. I saw Proxy debug message (maybe just once) from session.go and Message protocol.Pong from listener.go.

Conclusions

I didn’t expect that the address of the remote device should be the address of the relay. In my mind, these are two separate things i.e. the remote device is not the relay. It was not intuitive to me that when relaying, and in the setup that I have created, that the address of the remote is now the address of the relay, at least as far as setting things on the client side is concerned. I was also led astray by the GUI in Expt 1.

1 Like
8

If the only way to reach the device is the relay, devices address is the relay. Imagine same as a mail forwarding address.

I think most of the issues come here is that you disabled discovery which then requires you to wire up addresses manually.