GUI documentation / helpfile

Support
1

I am looking for a document explaining the effect of all possible settings syncthing settings, particularly related to the gui.

And I can not find it …

As example actions => settings => connections

  1. Sync Protocol Listen Address
  • it does refer to outgoing traffic not to in coming traffic (e.g. an relay). And normally the line starts with tcp or udp
  • multiple lines IPV4/IPV6 etc seems possible but that is not in line with the gui
  • most important question here is is it describing the remote address or the local address ; I think remote if so listen address ???
  1. Bandwith limit that is clear :slight_smile:
  2. Enable NAT traversal. Not clear what it is exactly doing … (I disabled it, since I feel it is trying to break my firewall, which I do not allow)
  3. Global discovery
    • not clear if it is related to being discovered or to discover outside the local vlan ?? or something else
    • and how does this process work ?? I normally forbid discovery of my network (other vlans)
  4. Local discovery?
    • again is it discovering others or being discovered
    • where and how
    • default what is the default and what options are there?
  5. Relaying
    • is it allow using a relay of acting as an relay

Just as example that the GUI is IMHO far from clear and I am seriously missing help entries next to all these fields

2

Hello @louis !

I recommend that you visit https://docs.syncthing.net/ . After doing that, don’t hesitate to get back in case something is still unclear. :slight_smile:

3

I did have a look at that url even before I wrote the thread.

However, I can hardly find any relation between the documentation over there and the GUI screens.

If there is any please explain where the documentation is as related to actions => settings => connections

Note that I did setup a private relay. And I could not even find in the docs where the relay config file was. After some revers enginering I found the config file and after some trail and error / testing I managed to use that file … however … things have room for improvement

4

The Docs may not be perfect, but I do believe you could find answers to most of your questions there. Obviously, reading everything from cover to cover isn’t exactly feasible, however I would suggest starting with https://docs.syncthing.net/intro and https://docs.syncthing.net/users/faq.

On a side note, most of the aforementioned settings aren’t really supposed to be tweaked or disabled unless you know exactly what you’re doing :sweat_smile:. The main idea is that the average user can install Syncthing and just start using by adding and sharing a folder without any additional tinkering.

5

I am digging deeper and deeper into the syncthing and the docs. Still looking for answers.

Below what I discovered up to now.

Not ‘comfortable’ / ‘not a good idea’ the names used in the GUI do NOT match the names used in the config file and/or documentation.

Here a limited version of the ‘translation table’

GUI-naming vs Config/Advanced naming

  • GUI “Sync Protocol Listen Addresses” = Advanced “Listen Addresses”
  • GUI “Enable NAT traversal” = Advanced “NAT Enabled”
  • GUI “Global Discovery” = Advanced “Global Announce Enabled”
  • GUI “Local Discovery” = Advanced “Local Announce Enabled” ([ff12::8384]:21027 ; IPV6 FF02::/16 is the prefix for a link-local multicast)
  • GUI “Global Discovery Servers” = Advanced “Global Announce Servers”
  • GUI “Enable Relaying” = Advanced “Relays Enabled”

After knowing this mapping I did find some info in Configuration Tuning — Syncthing documentation

But I do not yet know the answers on all questions I have. Never the less some info below as related to the connection GUI and the 'Tuning for LAN-only ’ section of the indicated html page

Sync Protocol Listen Addresses

Very, very strange the “Sync Protocol Listen Addresses” seems to contain settings related to both

  • outgoing traffic (e.g. a relay string) as (listen is not appropriate here)
  • in coming traffic ‘listening addresses’ (listen is correct here!)

For restricting sync traffic to only LAN

relaysEnabled

Set to false to disable relaying sync traffic through servers other than your sync partners.

  • Note that my private relay is the main/only connection point between my private clients!
  • an explicit defined (private) relay-server is not part of your sync partners (I did test).
  • so you have to turn on “Enable Relaying” to reach you (private)relay

When relays are used, those that you connect to can see your device ID and public IP address, but not the synchronized data, as that is encrypted.

natEnabled

Set to false to disable opening up UPnP and NAT-PMP port mappings and pinholes, and to disable hole punching. This reduces the ability for sync partners to connect on the Internet.

  • I personally forbid that here and in my firewall => advice turn it off
  • For restricting other things to only LAN

local Announce Enabled

no description available, however I assume using multicast on the local lan to find other think thing devices

Issue: not clear how that is related to a defined “Listen Addresses” e.g. a relay server!

  • does the relayserver string overrule the default listening address ? or is it additional?
  • are relays always tcp-only? (there is no tcp and / or other protocol id)
  • does the relay string block the default relays?

globalAnnounceEnabled Set to false to disable use of Global Discovery servers, which know your device ID and public IP address when being used. The discovery servers are used by your sync partners to discover your IP address from your device ID.

Questions:

  • What / which are the “Global Discovery servers” ?
  • does your private relay function as a discovery server ? (will it connect to your mobile clients on the internet ??)

On Android, local discovery is known to usually not work, so either global discovery or hard coding IP addresses is often required.

  • can android devices communicate with private relays !!??

I assume that you need this functionality to reach clients, even your own clients if they do not have a fixed address (e.g. on the internet) do not use non-LAN IP addresses in the config

If it’s not obvious, do not hard code non-LAN IP addresses, if you want to keep LAN-only

Also interesting how to combine access to private clients (via my private relay) with access to other clients (in a secure way).

So far my actual findings

6

I disagree: Syncthing is registering with a relay to listen for new connections here, from the relay.

I’m not sure what question you’re asking regarding restricting traffic just to the LAN. You can configure Syncthing to use only the LAN. You can configure Syncthing to use the global relays. You can configure Syncthing to use only your private relay.

You’re correct on natEnabled.

Local announcements are related to listen addresses: If you want Syncthing Devices to find each other on the LAN, you need both.

Global Discovery Servers are being hosted by nice people on the Internet. Discovery and Relaying are separate functions – Discovery allows Devices to find each other (you don’t need this if Devices have another way to find each other), and Relays allow syncing to occur when direct connections cannot be made.

7

Actually, all default discovery servers are hosted by the Syncthing Foundation :sweat_smile:. When it comes to relays, they can be hosted by anyone willing to do so, but the same isn’t true with discovery servers. Of course, you can run your own and point your Syncthing instances at it, but there is no “public pool” of discovery servers (as is the case with relays).

1 Like
8

I am frustrated that I have to put a lot of effort discovering how things work and how to set up things.

I know I certainly do want to do more complex things than an average user. That does not take away that I really think that it is far from clever to use different terms for the same parameter in the gui and in the documentation.

And each GUI item should have a help. Having said that again. It just cost me far more time to understand settings and testing behavoir than it should.

Let me just mention two issues I still have to solve / test etc

  1. assume I install syncthing on laptop1 and are some where on the road. Laptop2 are at home. Both will try to communicate via my private relay.

Will that work? Will my relay be capable to connect laptop1 with laptop2 ?

I would not be surprised, however there is no discovery server involved … I think … I can imagine my relay provide that function … however I do not know. I have to test that!

If it does not work I have to find a way to solve that. Perhaps I have to setup a discovery service next to the private relay … /??

  1. Assume I also want to use syncthing to communicate with public clients. There are probably two ways
  • install a second syncthing client
  • add a second path to the outside world to the clients next to the path to my private relay

Have to find out. Note that my private relay is also the proxy separating internet and my private network.

9

Just to verify, are you using the current version of Syncthing? At least in the Advanced Configuration, all options have help links right next to them that move you to the relevant entry in the Documentation if you click them.

10

That’s the way of the world. This is open source software. If you think there are improvements to make, you can certainly develop them yourself.

I can’t tell you that until you describe how they’re connected. For example, If your relay is available on the Internet, your two Devices can connect to it, and they know where to look (through Discovery or Device configuration), then yes.

I don’t understand the use case here. Please explain.

11

Thanks for the correction!

12

I think the client is creating / setting up an connection with the relay. So the initiative party is the client.

I do not think I would name that listen address. The name ‘Sync Protocol Listen Addresses’ is a bit closer.

What ever it is strange that the protocol to be used is not included in the ‘connection string’

Also strange that the relay string is pointing to the destination where tcp://0.0.0.0:22000 is pointing to local really listen address

and of course you probably can probably combine e.g. combine a IPV4 and a IPV6 address

And perhaps a relay can forward from an IPV4-client to an IPV6 client …

I have to dig deep and to test to find out

that is the problem

13

I think one of the issues here is that out of the Syncthing’s massive userbase, extremely few run their own relays (let alone discovery servers), and even fewer have interest in working on improving the documentation on those, so you basically need to experiment and fill the gaps yourself… Contributions to the Documentation are always welcome though!

14

Some general clarifications, feel free to suggest a pull request for how to better explain that in the docs once you have understood the matters yourself:

Discovery servers are separate from, and orthogonal to relay servers. The latter does not provide any way of finding other devices for direct connections.

“Listening” on some endpoint or address means that others can connect there to talk to your local instance. That is the case with relays. Syncthing registers with the specified relay and whoever knows about this fact can use the relay server to make a connection. Finding out about it is done through the global discovery protocol, where one instance announces on the discovery under which addresses (or relay servers) it could be tried to get a connection.

However, just registering at the same relay server (as listener) is not enough for two devices to talk to each other. To make it work, at least one end must be told that the other one should be tried under the relay address. This is done by including a specific relay address in the remote device’s address field (Edit Device dialog). Unless global discovery is enabled, in which case the relay will be discovered and tried automatically.

Note that both devices try to reach each other, so it works if one direction succeeds.

If your relay is reachable via IPv6 and IPv4, then yes it can act as a mediator between devices with either protocol.

With your private relay server, you either need to enable global discovery, or configure the relay address on both sides as a listening address and as part of the remote device addresses list. The latter sounds closer to what I think you want to achieve.

Yes, the documentation sometimes uses slightly different terms. That’s because it tries to explain the concepts and the configuration file format. We don’t really have much documentation for the actual GUI.

And what you are trying to set up is very much not the typical usage. By default, Syncthing tries hard to establish a connection, preferably direct. It uses some helper mechanisms to increase the probability of success, such as global discovery. Relays are a last resort if direct connections are not possible. If you want to disable all those convenience mechanisms for added security / isolation, then of course it gets harder because you need to take care yourself. And manually specifying relays addresses without discovery is so inconvenient that the only few users doing that are probably very technically involved and able to find out what Syncthing does and needs, without elaborate documentation describing the process. That’s why probably nobody cares to write it up.

The lacking GUI documentation is certainly a sore spot, waiting for your contribution to improve it.

4 Likes
15

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