Using custom discovery server and custom relay server on my VPS.
discosrv - discovery_ip:8443, version 0.13, relaysrv - relay_ip:22067, version 0.12.18
device1, device2, android – connecting with each other, device3 behind SOCKS5 proxy – connection error, other devices disconnected.
This configuration perfectly work with 0.12.25 clients and discosrv 0.12, all devices can connect with each other, after upgrade to 0.13 device 3 cannot connect to other devices.
device 3 Windows client log:
[BCHLI] 08:18:06 INFO: syncthing v0.13.4 "Copper Cockroach" (go1.6.2 windows-amd64) WIN-P6RP886TVDJ\Administrator@WIN-P6RP886TVDJ 2016-05-26 09:16:08 UTC
[BCHLI] 08:18:06 INFO: My ID: xxxx
[BCHLI] 08:18:06 INFO: Single thread hash performance is ~188 MB/s
[BCHLI] 08:18:06 INFO: Ready to synchronize xxxx- xxxx - xxxx - xxxx - xxxx (readwrite)
[BCHLI] 08:18:06 INFO: Using discovery server https://discovery_ip:8443/v2/?id=XXXXXX
[BCHLI] 08:18:06 INFO: Completed initial scan (rw) of folder xxxx - xxxx - xxxx - xxxx - xxxx
[BCHLI] 08:18:06 INFO: Device CMLLGPN is "device1" at [dynamic]
[BCHLI] 08:18:06 INFO: Device FWP74MK is " device 2" at [dynamic]
[BCHLI] 08:18:06 INFO: Device XWOUZVI is "android" at [dynamic]
[BCHLI] 08:18:06 INFO: Device BCHLII5 is " device 3" at [dynamic]
[BCHLI] 08:18:06 INFO: GUI and API listening on 127.0.0.1:8384
[BCHLI] 08:18:06 INFO: Access the GUI via the following URL: https://localhost:8384/
[BCHLI] 08:18:06 INFO: Proxy settings detected
[BCHLI] 08:18:06 INFO: Proxy fallback disabled
[BCHLI] 08:18:08 INFO: Joined relay relay:// relay_ip:22067
2016/05/31 08:24:59 Supervisor connections.Service: connections.Service: Failed service 'relay:// relay_ip:22067' (1.000000 failures of 5.000000), restarting: true, error: interface conversion: net.Conn is dialer.dialerConn, not *net.TCPConn, stacktrace: goroutine 52 [running]:
github.com/syncthing/syncthing/vendor/github.com/thejerf/suture.(*Supervisor).runService.func1.1(0xc082166b60, 0x2)
c:/jenkins/workspace/syncthing-release-windows/src/github.com/syncthing/syncthing/vendor/github.com/thejerf/suture/suture.go:550 +0xb6
panic(0xb7f6a0, 0xc08264b140)
c:/go/src/runtime/panic.go:443 +0x4f7
github.com/syncthing/syncthing/lib/connections.(*relayListener).Serve(0xc082422f00)
c:/jenkins/workspace/syncthing-release-windows/src/github.com/syncthing/syncthing/lib/connections/relay_listen.go:77 +0xc92
github.com/syncthing/syncthing/vendor/github.com/thejerf/suture.(*Supervisor).runService.func1(0xc082166b60, 0x2, 0x1e52290, 0xc082422f00)
c:/jenkins/workspace/syncthing-release-windows/src/github.com/syncthing/syncthing/vendor/github.com/thejerf/suture/suture.go:556 +0x65
created by github.com/syncthing/syncthing/vendor/github.com/thejerf/suture.(*Supervisor).runService
c:/jenkins/workspace/syncthing-release-windows/src/github.com/syncthing/syncthing/vendor/github.com/thejerf/suture/suture.go:559 +0x58
[BCHLI] 08:25:01 INFO: Could not join relay relay:// relay_ip:22067: Incorrect response code 2: already connected
I’ve fixed the panics, but I think there remain issues with relays over proxy… If you like you can try the latest dev build (linked at the top of the page) for that fix and see if you get the same errors that I do.
Ugh :). In the meantime I got the build from github.com working. No panics anymore, but still no successful connection. Would it help to post e.g. my logfile? If yes: where, and is there a simple way to obfuscate my private details?
Download from this link: https://build.syncthing.net/job/syncthing-pr-windows/ buld syncthing-windows-amd64-v0.13.4+35-g6b9f3c3.zip. My problems was resolved. I can connect android device with PC behind SOCKS proxy. Thank you for your help!
That link is whatever the latest pull request is, and currently that’s something entirely different. Use the “for Windows” link at the top - it’s fixed now.
I tried to see if I could fix something myself, but I don’t know enough about go syntax… conn.RemoteAddr() gives gives an Addr interface (https://golang.org/pkg/net/#Addr), but what does .(*net.TCPAddr) do?
.(*net.TCPAddr) is a type assertion, which extracts the inner type from the interface or (in this case) panics when it isn’t what we say it must be. The “root” issue here being that the code expects a regular TCP connection, which is usually a safe bet. However we’re wrapping it in a proxy connection which lies about the remote address (the actual remote address is just the proxy).
