Hi All,
I’ve got to set up a pair of Solaris11 machines with synced directories.
I’ve got the machines set up in Virtualbox, I’ve downloaded the latest binary. It runs, I’ve told each machine about the other, netstat shows the connections to port 22000, but the machines say “Disconnected”.
The error message is: [3ECQP] 15:02:14 INFO: TLS handshake: read tcp 192.168.0.1:22000: connection timed out
That’s nonsense, as I can see the connections in netstat.
Help?
Do you see the outgoing connections or the incoming connections?
Also, I suggest you use netcat to verify that they can actually talk to each other.
Note that there might be various magic you need to do in virtualbox to get a shared network between the two vm:s. There’s nothing virtualbox specific needed on the Syncthing side, so basically this is down to your network setup.
The guests are connected. I can telnet on port 22000 from each to the other, and netstat -an on each shows the incoming and outgoing connections as ESTABLISHED.
If I telnet into port 22000, what should I see come back? Is it an encrypted connection and should I use openssl s_client instead?
Its most likely not allowing multicasts broadcasts killing local discovery
Local discovery works. Whether I explicitly set the address, or leave it set to dynamic, the connections still get made.
I’ve got the guests’ networking set up in bridge mode, so that I can connect to the from the host, and I can use tcpdump to capture the traffic. Here’s a base64.pcap of a connection. It does the normal 3 way handshake, the client(.166) pushes some data to the server(.165) and gets the ack. However, the client doesn’t seem to see the ack, and so repeats the push a number of times (and gets the acks). After ~150 seconds it all times out and both ends rst the connection.
I do see udp broadcasts to port 21025.
Edit: snipped base64 of something // @calmh
So acking et all are out of our control. Can you provide the reason for disconnection from both sides? Also, as I said (apparently in a different thread), if one of them is a weak device, you might want to increase the ping timeout, as scanning and db updates might overwhelm it and cause it to timeout
So acking et all are out of our control
Sure, I get that, but it’s not a problem with missing acks. After the 3 way handshake, the client pushes a packet to the server (and gets the ack). However the server doesn’t send any data back. Hence the client resends a number of times (and gets the ack for each). It seems to be that the server is not seeing the incoming data from the client, because after 150 seconds the server sends a rst, and the client does the same N.B. it’s a rst, not the usual fin/fin-ack/ack 3 way teardown.
It’s nothing to do with weak/full/busy devices, both machines are identical virtuals in the same Vbox. Since both ends keep saying
[3ECQP] 14:23:39 INFO: TLS handshake: read tcp 192.168.1.165:22000: connection timed out
[3ECQP] 14:24:39 INFO: setsockopt: option not supported by protocol
I’d guess that the TLS stuff isn’t working. I downloaded the prebuilt binary, what system was that compiled on? It may be some missing library, or version incompatibility.
So it seems that setsockopt fails, but it’s not clear where. Perhaps its something missing inthe solaris kernel that we expect to find. I don’t run solaris, so its hard for me to say whats wrong, but you can enable STTRACE=net env var which should start printing line numbers on where the error happens, and we can debug this further. I think if we fail to set some options we might just throw the connection away.
[monitor] 2015/07/31 15:58:16.501324 monitor.go:94: INFO: Starting syncthing
[start] 2015/07/31 15:58:16.538299 main.go:784: INFO: Audit log in /export/home/ian/.config/syncthing/audit-20150731-155816.log
[M5GAI] 2015/07/31 15:58:16.852064 main.go:473: INFO: syncthing v0.11.17 (go1.4.2 solaris-amd64 default) unknown-user@syncthing-builder 2015-07-26 09:25:40 UTC
[M5GAI] 2015/07/31 15:58:16.852374 main.go:474: INFO: My ID: M5GAI7M-KQUIIPM-FZTKK3N-TP2ZG6F-JDM2OGA-T3YOSEM-GKITTEY-44QGRAF
[M5GAI] 2015/07/31 15:58:16.905140 model.go:194: OK: Ready to synchronize default (read-write)
[M5GAI] 2015/07/31 15:58:16.905520 main.go:815: INFO: Starting web GUI on http://192.168.1.165:8384/
[M5GAI] 2015/07/31 15:58:16.908025 rwfolder.go:317: INFO: Completed initial scan (rw) of folder default
[M5GAI] 2015/07/31 15:58:17.208692 main.go:891: INFO: Starting local discovery announcements
[M5GAI] 2015/07/31 15:58:17.209373 discover.go:126: INFO: Local discovery over IPv6 unavailable
[M5GAI] 2015/07/31 15:58:17.209870 upnpsvc.go:46: INFO: No UPnP device detected
[M5GAI] 2015/07/31 15:58:17.210169 main.go:677: INFO: Device M5GAI7M-KQUIIPM-FZTKK3N-TP2ZG6F-JDM2OGA-T3YOSEM-GKITTEY-44QGRAF is “syncthing1” at [dynamic]
[M5GAI] 2015/07/31 15:58:17.210509 main.go:677: INFO: Device 3ECQPQP-IZOLSSU-OCSNPSU-WUBP7FE-4D7G6RL-QX5AVCH-BJZGUHJ-MP43TQL is “syncthing2” at [dynamic]
[M5GAI] 2015/07/31 15:58:17.210833 connections.go:202: DEBUG: listening on 0.0.0.0:22000
[M5GAI] 2015/07/31 15:58:17.228574 gui.go:221: INFO: API listening on 192.168.1.165:8384
[M5GAI] 2015/07/31 15:58:18.210755 connections.go:278: DEBUG: dial 3ECQPQP-IZOLSSU-OCSNPSU-WUBP7FE-4D7G6RL-QX5AVCH-BJZGUHJ-MP43TQL 192.168.1.166:22000
[M5GAI] 2015/07/31 15:58:18.220956 connections.go:329: INFO: setsockopt: option not supported by protocol
[M5GAI] 2015/07/31 15:58:27.372876 main.go:1024: INFO: Automatic upgrade: couldn’t fetch release information
[M5GAI] 2015/07/31 15:58:48.051574 connections.go:222: DEBUG: connect from 192.168.1.166:48952
[M5GAI] 2015/07/31 15:58:48.051762 connections.go:329: INFO: setsockopt: option not supported by protocol
[M5GAI] 2015/07/31 16:03:29.070890 connections.go:302: INFO: TLS handshake: read tcp 192.168.1.166:22000: connection timed out
[M5GAI] 2015/07/31 16:03:31.071620 connections.go:278: DEBUG: dial 3ECQPQP-IZOLSSU-OCSNPSU-WUBP7FE-4D7G6RL-QX5AVCH-BJZGUHJ-MP43TQL 192.168.1.166:22000
[M5GAI] 2015/07/31 16:03:31.089930 connections.go:329: INFO: setsockopt: option not supported by protocol
[M5GAI] 2015/07/31 16:03:59.103365 connections.go:231: INFO: TLS handshake: read tcp 192.168.1.166:48952: connection timed out
[M5GAI] 2015/07/31 16:04:31.211954 connections.go:222: DEBUG: connect from 192.168.1.166:41537
[M5GAI] 2015/07/31 16:04:31.212132 connections.go:329: INFO: setsockopt: option not supported by protocol
[M5GAI] 2015/07/31 16:08:41.958387 connections.go:302: INFO: TLS handshake: read tcp 192.168.1.166:22000: connection timed out
[M5GAI] 2015/07/31 16:08:45.959147 connections.go:278: DEBUG: dial 3ECQPQP-IZOLSSU-OCSNPSU-WUBP7FE-4D7G6RL-QX5AVCH-BJZGUHJ-MP43TQL 192.168.1.166:22000
[M5GAI] 2015/07/31 16:08:45.968605 connections.go:329: INFO: setsockopt: option not supported by protocol
[M5GAI] 2015/07/31 16:13:56.835914 connections.go:302: INFO: TLS handshake: read tcp 192.168.1.166:22000: connection timed out
[M5GAI] 2015/07/31 16:14:04.841687 connections.go:278: DEBUG: dial 3ECQPQP-IZOLSSU-OCSNPSU-WUBP7FE-4D7G6RL-QX5AVCH-BJZGUHJ-MP43TQL 192.168.1.166:22000
[M5GAI] 2015/07/31 16:14:04.843523 connections.go:329: INFO: setsockopt: option not supported by protocol
This was announced on comp.os.solaris a few weeks back, it’s a free download.
http://www.oracle.com/technetwork/server-storage/solaris11/overview/beta-2182985.html
Solaris is my primary Syncthing platform, though as SmartOS (illumos). It works perfectly fine there, so I would still suspect something about the virtual box setup, or some interaction between Solaris and virtual box.
I’ve downloaded syncthing-solaris-amd64-v0.11.18 and that doesn’t work either, in exactly the same way i.e. the client makes a tcp connection to the server (does the three way handshake), and then tries to start a tls connection, but the server does not respond.
I ran it inside truss, and nowhere does it attempt to load any ssl libraries, surely that’s not correct?
Its statically compiled and uses Go’s stdlib for tls.
Problem located somewhere Solaris 11.3 internally (looks like problem w/ OpenSSL package). Switch back to solaris 11.2 SRU Oracle Solaris 11.2.11.5.0 - problem with TLS timed out completely disappeared. Still looking for solution, but now this is not very important (two or maybe more weeks later i’ll check fresh release 11.3).
This: root@ext:~# go version go version go1.5.2 solaris/amd64
… was a complete solution for this problem.
Update golang on solaris and rebuild syncthing.
Note that the binaries on Github are also built with 1.5.2, so should probably work about equally well then.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.