Is the affected device running on Windows by any chance?
I think this is caused by TCP port reusing not being supported in the local interface, which causes syncthing to use a normal ephemeral port during announce. (Normally, syncthing would try to announce to the discovery server via the sync port, 22200). The discovery server records all ports used by the announcing device, which then causes the list to be filled with ephemeral ports.
The TCP port reusing may break for various reasons, but it tends to happen more on Windows machines.
If you want more data on this, I suggest enabling debug logging (dialer and discovery).
Yeah, I think one of the announced addresses contains a 0 port for whatever reason, which is then replaced by the actual remote port in stdiscosrv, which doesn’t work properly if the dialer uses ephemeral ports.
Debug logging will probably show what’s going on.
I am already running in debug logging but see nothing about extra ports being announced. right now I’m struggling to setup a reverse proxy in front of stdiscosrv to be able to capture plain http traffic between the reverse and discovery server. unfortunately stdiscosrv tells nothing relevant in -debug mode
can it be disabled? this will multiply by hundreds of devices resulting in repeated loops of tcp resets, and that would be anything but “good measure” for my network
it’s 2 packets multiplied by hundreds or more devices repeated all over. I need to reduce traffic to minimum because it’s a high latency low bandwith infrastructure
plus, I don’t think it’s normal for clients to search for each other on invalid ports in an infinite loop. at least open/bind to that port you are announcing.
Feels like you need specialised software if you care about that. Syncthing chats quite a lot willy nilly, and priority is connectivity rather than minimal bandwidth.
still remains a valid point that clients are instructed to connect to other clients to ports on which they don’t listen. that’s got nothing to do with being chatty, but sounds rather a design bug to me.
it’s like meeting a person and telling them call me on this number, and oh, look me up in the directory, but hey, you might find an invalid number of me there.
Clients don’t know what ports the nat mapped for them, hence the notion of :0, which gets replaced by the outgoing connection port by the discovery server.
So, as already mentioned port 0 gets replaced by the dialing (source) port of the announce, which should be a valid port that syncthing also listens on (like 22000). This is done via TCP port reuse, so that the outgoing port is the same as the incoming port (i.e. you’ve both a TCP client and a TCP server socket on the same port). This causes the annoucement to be sent from port 22000, which your NAT might then remap to whatever. The discovery server records the NAT-mapped port so that hole punching knows where to knock.
In your case this goes wrong (which can happen due to unsupported operating systems, network interface or routing specifics), in that case syncthing falls back to letting the operating system choose an outgoing port. This port is obviously not setup for incoming connections, so it causes the behaviour you’re seeing. This is not the intended behaviour of the announcement, but rather the result of TCP port reusing not working properly for some reason.
There’s debug logging in syncthing which logs TCP port reuse problems, so data from that could help.
there is no nat involved. the nat is disabled in configuration. there is direct routing via isolated network. there is no relay enabled. there is no local announcement enabled. there is no firewall.
it’s just plain simple host A to host B communication via standard router.
I fail to see any logical reason to still announce :0 in this case.