OK after further testing I have found out the following:
We are receiving the wrong mapping from the discovery server - our central server is also unable to connect to these clients until it receives a connection from the client then it receives the correct mapping.
Discovery server response:
Nov 26 11:27:03 my-host syncthing[19194]: 00000000 9d 79 bc 39 00 00 00 20 a8 21 b3 19 be 9a da 15 |.y.9… .!..|
Nov 26 11:27:03 my-host syncthing[19194]: 00000010 b2 cc d4 77 67 2e 96 0a 79 7a dc 1a 12 28 4d c8 |…wg…yz…(M.|
Nov 26 11:27:03 my-host syncthing[19194]: 00000020 b5 ca 90 4d 4c cf fb d7 00 00 00 01 00 00 00 04 |…ML…|
Nov 26 11:27:03 my-host syncthing[19194]: 00000030 1f 36 57 bb 00 00 6e 70 00 00 00 00 |.6W…np…|
Nov 26 11:27:33 my-host syncthing[19194]: [2GSRE] 2014/11/26 11:27:33.033049 main.go:965: DEBUG: connect from 31.255.255.187:51382
Nov 26 11:27:33 my-host syncthing[19194]: [2GSRE] 2014/11/26 11:27:33.281825 main.go:920: INFO: Established secure connection to VAQ3GGN at 192.168.1.248:28272-31.255.255.187:51382
Or is that just using the connection it received rather than making a connection to them as well?
I’ve also just noticed that my laptop isn’t putting anything into the log for UPnP mapping other than Local Discovery. There are no errors either… Is there an extra flag I need to set in STTRACE?
Perhaps global discovery is disabled, or the server address is unset?
As for you getting incorrect mappings, it’s your servers fault for advertising wrong stuff.
It most likely advertises wrong stuff because UPnP is failing.
All the nodes have Global+Local discovery on with dynamic addresses set. I’m seeing nothing in my laptop about the UPnP port being mapped using a Virgin Media Superhub 2ac, there aren’t even any errors! Manually forwarding the port allows devices to connect to me.
I think all of the issues being faced here are with BT and Virgin Media’s network equipment given to customers. Seems unlikely we’ll get a fix from them anytime soon… They are the biggest ISPs in the UK.
The protocol is slowly moving to DST (TLS over reliable UDP) which should not have these issues at all.
But you are not alone, as I have a plus.net Thomson router, which supports UPnP and works with uTorrent, Skype et al, but it doesn’t seem to be working with Syncthing so I end up mapping ports manually.
There might be something wrong with the UPnP code, but I haven’t had a chance to fire up Wireshark to investigate what’s wrong.
Does Syncthing manage to find the UPnP devices, or does it just say 0 devices found?
It says 0 devices found on my Laptop so that would be using the SuperHub. All the other devices get a successful mapping (those using BT Hubs) but still unable to connect to those.
I’m just waiting to receive a log from one of those devices.
In the mean time I have downloaded a UPnP tester from: http://noeld.com/programs.asp?cat=dstools and that shows as though syncthing already mapped a port through UPnP but didn’t log it? I know it was done by Syncthing as I’ve looked at the source and it adds the description “syncthing”
The SuperHub 2ac is running 1900/tcp open sip FedoraCore/6 UPnP/1.1 MiniUPnPd/1.7
Very bizarre. I’ve just changed the listening port on Syncthing and once it restarted this appeared in the log:
[AAW47] 2014/11/26 13:31:05.360249 main.go:618: INFO: Starting web GUI on https://127.0.0.1:8080/
[AAW47] 2014/11/26 13:31:05.974670 upnp.go:106: INFO: Starting UPnP discovery…
[AAW47] 2014/11/26 13:31:11.976508 upnp.go:133: INFO: UPnP discovery complete (found 1 device).
[AAW47] 2014/11/26 13:31:12.023767 main.go:742: INFO: Created UPnP port mapping for external port 28470 on UPnP device ‘VMDG490’ (192.168.0.1).
[AAW47] 2014/11/26 13:31:12.023767 main.go:1085: INFO: Starting local discovery announcements
I then restarted the server again and it produced the same output. Seems intermittent with the Virgin Media one, not sure why. I will wait for the log from one of the BT clients and post the UPnP logs from it once received.
Yeah, so if you change the listen port I am sure it will get a new mapping as its a 1:1 thing.
Now if you STTRACE=discovery you’ll see that it’s most likely announcing the correct (mapped) port, and then clients querying discovery should get the right port too.
The devices that are not working are probably having issues getting the mapping in the first place.
