Here are the screenshots. I noticed, that the files I deleted yesterday on the windowsNode (FIN) are shown on FIN itself (upper screenshot) as synced to the AndroidNode (PIX) today. But it took many hours. I just deleted an other file on FIN, to see, if it going faster now, and it does not seem to be synced with acceptable speed (“1 items. ~0B”).
By the way: I do not use “Global Discovery” or “Relaying”. So the clients are using fix IPs, which are set up in each node.
A thing I noticed: on the AndroidNode (PIX) the WindowsNode (FIN) is configured as “tcp://10.0.0.20:22000” but in PIXs web interface, there is a different port displayed “10.0.0.20:54122” is that correct?
The 0B mentioned here isn’t about the speed, but rather the size. The 0B here specifically is used by Syncthing to mark deleted files (unless you’re actually syncing empty files).
Using static IPs should be fine. I’d guess the 54122 port is being used because the default 22000 wasn’t available when Syncthing was started.
I’m curious about the funky version string reported on Android though, i.e. v1.17.0-dirty. Is this a self-compiled version or, if not, can you tell where exactly it comes from? It surely doesn’t look like the official app…
In a normal environment that different port may cause no trouble. But my network is configured quite …ehm… conservative. Therefore the local firewall on every node only let pass traffic to <TargetNodeIP>:22000. So maybe this is the reason for the extrem slow / not working sync. Let me check that out.
PS. The “dirty” Android version is nothing fancy. I think, it comes from the fact, that Syncthing was not installed over Google Play store, but by downloading the APK from the Syncthing page.
It seems, that SyncThings unallowed and undocumented usage of the port 54122 caused that problem. From the moment I allowed ST to use all ports, files are synced instantly.
Why Syncthing is using ports (that are not configured to be used) by its own?
