Two syncthing instances in one machine

[cosas]

Hi

I have a setup where 2 ST instances run in a single machine. The first instance runs as a always-on hub for various shares with friends/family, non critical, so I let it triggered to my own login. Let’s call this machine the server.

The second instance runs OK for my wife (first idea was kind of backup… I known, ST isn’t…!), but she seldom opens a session on this machine. So I figure running her instance as a user service. I didn’t yet set this ATM. Her GUI it set at 127.0.0.1:7374, listens on tcp://:myOwnSpecialTcpListenPort+1, I’m 99% sure these two are OK.

But I also set her “Local Announce Port” to 21028 (because I thought it must be different from my own instance 21027 default) and today reading the official doc I read this UDP port is used for both send and receive local discovery.

On her laptop ST configuration she has as “Other devices” among others the ID of her instance in the server, and remote friends, all listening/speaking over 21027.

At the time of start writing I thought I’d ask an advise if I also had to change “Local Announce MC Addr” from [ff12::8384]:21027 to [ff12::8384]:21028 for her because I don’t know anything about IPv6. Now I begin to guess the only solution is to give up the idea to have 2 instances of ST in a single machine working at best because 2 different UDP ports make like 2 jails that can’t see each other and using the same will make collisions or errors.

Please confirm, is the single solution is setting my wife backup shared folder into my own account?

[calmh (Jakob Borg)]

Local discovery over IPv4 won’t ever work with two instances on the same machine. Local discovery over IPv6 might work, depending on the operating system and whatnot.

[Andy (Andreas Kaelber)]

I can only partially confirm that. I have 3 instances running on my 3 Synology servers, including one Docker instance each. The ports are assigned accordingly

Instance 1: 22000, 21027, 8384, [ff12::8384]:21027 (SPK Kastelo)
Instance 2: 22001, 21028, 8385, [ff12::8385]:21028 (SPK Safihre)
Instance 3: 22002, 21029, 8386, [ff12::8386]:21029 (Docker)

Instance 1+2 are connected and Instance 3 is not connected with any Instance. Instance 1+3 are seen and vice versa when I go to “Add device”. Instance 2 is not seen by Instance 3 and vice versa.

If I assign port 21027 the same for all, the instances will see more and different ones, but not all of them are not connected, although actually all that are not connected should be seen. I haven’t understood that yet.

On an Android I also have 2 instances with the same pattern for the port assignment, this also works without troubles.

[calmh (Jakob Borg)]

It’s literally impossible for two devices to see each other if they’re using different ports for local discovery.

[Andy (Andreas Kaelber)]

This is also a bit strange for me, but the picture is the same on every server.

From what I’ve read so far, it doesn’t seem to be a disadvantage to assign the same port 21027 for local discovery to all instances, is it? In that sense, it would be more of an advantage.

[calmh (Jakob Borg)]

Two processes can’t listen on the same port for ipv4 broadcasts. On ipv6 it may work, in which case it does no harm.

[Andy (Andreas Kaelber)]

@calmh

processes can’t listen on the same port for ipv4 broadcasts

The Docker configuration I set up as follow:

In my opinion the container is closed and outside only visible with local ports in the coloumn “Lokaler Port”. Is it still possible that the container communicate with the system over the container ports? That could explain why instance 1+3 can see each other.

[calmh (Jakob Borg)]

I don’t know. I don’t think docker forwards UDP broadcasts or multicasts in any case? Of course net=host is a different case if you use that.

[basiliscos (Ivan Baidakou)]

I use the following trick:

 iptables -t nat -A OUTPUT -p udp --dport 21027 -j DNAT --to-destination 127.0.0.1:21026

i.e. as another instance should moved to listen 21026 port, and when UDP-broadcast packet is sent to the default port (21027) it is also copied the port 21026, and voala!.

The trick works on linux. No idea about other OS’es.

[cosas]

Oooch, what a genius idea

I guess you have to do this on all the devices in the LAN remaining hear/speak over the standard 21027 isn’t? Why not tweaking the firewall only on the device(s) running multiple ST instances this way:

iptables -t nat -A OUTPUT -p udp --dport 21026 -j DNAT --to-destination :21027
iptables -t nat -A INPUT -p udp --dport 21027 -j SNAT --to-destination :21026

?