I have setup two devices: one is an android phone and the other one is a router. Local and global discovery is enabled as well as relaying. Everything works great when they are on the same network and the speed is awesome. Sync is by-directional and I have not opened any ports on the router so that I can test the relays.
Once I switch the phone to cellular data, syncing stops working. I have checked all “discovery-v4-*.syncthing.net” servers and both devices are registered there.
I have created new files on each device. The android device now knows there is an additional file created on the router (via Global/Local State) and two new local files, but the router only know about the new local file and not about the two new files on android. And the devices are not syncing.
Am I doing anything wrong here? Not sure if this is the android app issue or not.
I have noticed that the timestamps on “discovery-v4-*.syncthing.net” keep changing, but the “Last seen” date under “Remote devices” for each device is still displaying the time when both devices were on the same network several hours ago.
Any suggestions what I could check in my configuration?
Check that you’re using the default listener setup, that relaying is enabled, and that both listeners are green (“2/2”). On both devices. If you see something other than a green two-out-of-two, hover on it.
None of them will use relays, and probably none of them allow incoming TCP connections when the phone is on cellular.
To use the default relays, use default or add dynamic+https://relays.syncthing.net/endpoint to the list of addresses.
This is a little bit undocumented and unfriendly, but default means tcp://:22000, dynamic+https://relays.syncthing.net/endpoint and the latter needs to be in there for it to accept incoming connections via the relay pool.
Are you saying that the use of relays is only possible when using default ports? The above configuration was an attempt to use custom ports. And you are correct, none of those will accept incoming connections: the phone is behind a NAT (from a cellular provided) and so is the other instance of syncthing.
I thought the local listen address and port would not affect relaying…
No, the thing is that accepting incoming connections from the relay pool is done as a listener. So for relays to work as designed it needs to “listen” on a relay connection. That dynamic+https thing means to talk to the relay pool, get a list of relays, and connect to one of them for accepting incoming connections.
It’ll still attempt outgoing relay connections without that, but if neither of the two devices listen for incoming connections via relays they will not be able to connect that way. (This is a useful configuration in some scenarios, but not in this case.)
I wonder if dynamic+https://relays.syncthing.net/endpoint can become a checkbox under “Sync Protocol Listen Addresses”: “Allow Incoming Connections via the Default Relay Pool”? Or something more user friendly…
Yes, something like that would be better probably. Note though that the default is to use relays and no additional configuration is needed. When you change the default however, this is one aspect that needs configuration that is far from obvious…
Mmm. I think the problem is mostly that “default” is extremely opaque in what it actually means. The reason we have it at all is that it make it easier to change what the defaults mean when they are not hardcoded into the config - for example, we can seamlessly introduce new listening methods as part of “default” for people who use that value. But if it had said, explicitly, tcp://:22000, dynamic+https://relays.syncthing.net/endpoint you would only have updated the port number and everything would have worked fine…
Using other relays, other relay pools or no relays at all are all good reasons to change the default, but it should be much clearer how to do this.
They are not really separate. “Listening” is how we get incoming connections. We can do that on TCP ports, via static relays, via dynamic relays, or on UDP ports (kcp://, although this is somewhat broken today). The config UI could certainly be more sophisticated, but these are all legitimate listening sources. By default we use two of them - a TCP port, and a dynamic relay pool.