[solved] Docker install "connected to myself (...) should not happen

Syncthing is installed via Docker on an Ubuntu Budgie 19.10 pc that is used as server. Syncthing is not installed on the host directly and the only clients connecting are 2 Android phones, on the same LAN.

Network info about the PC:

  • IP: 192.168.88.10
  • CIDR: 192.168.88.0/24
  • Gateway (router): 192.168.88.1

I have a MikroTik (RouterOS) router and I forwarded port 22000 to 192.168.88.10.

Now I get this error in the log, twice per second:

2020-04-05 12:03:09 Connected to myself (...-RIZ4VAM) at 172.18.0.4:22000-172.18.0.1:52498/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256 - should not happen

That SyncThing ID ending in RIZ4VAM is actually the SyncThing instance running in Docker. The IP addresses 172.18.0.4 mentioned in the log is not known to me but seems to be the local Docker IP address. I checked Portainer, and SyncThing is connected to “docker_default” network, something that was created automatically.

Port 52498 is mentioned in the error, strangely, because I did not create a portforward for it.

This is how I installed SyncThing on the host:

  syncthing:
    image: linuxserver/syncthing
    container_name: syncthing
    network_mode: bridge
    restart: unless-stopped
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - UMASK_SET=022
    volumes:
      - ${USERDIR}/docker/syncthing/config:/config
      - ${USERDIR}/Documents:/documents:rw
      - ${USERDIR}/Pictures:/photos:rw
      - /mnt/pool/backups:/backups:rw
    ports:
      - '8384:8384'
      - '21027:21027/udp'
      - '22000:22000'

What should I change to prevent this error from happening?

This is because you have multiple syncthing instances running behind the same router, and when they announce themselves to the discovery server, it usually adds a <ip address visible on the connection>:22000 to the list of addresses, so your phones gain those addresses but in reality its mapped to your desktop. You can work around this by running different devices on different ports, 22001 etc.

1 Like

Maybe we should change the ... should not happen to ... happens all the time and is nothing to worry about or just not mention it at all and set the connection error to wrong device ID (port mapping error?).

1 Like

I thought it would be something like that. Although still a bit strange because I only see that docker IP address in the log of the host.

Anyway I was considering if I really need ‘Discovery’? It is a great feature. But if I would simply add the host (the pc) via IP:port to the devices, would I really need the local/global discovery?

If I would use a dynamic domain address, that forwards to the local pc IP, the devices can connect to the host when not connected to the LAN as well.

This way, I can disable local/gobal discovery and perhaps also “NAT traversal” as I have already forwarded port 22000?

If you have a static network there is no good reason why you need discovery

Great. I am trying to switch to static now:

On the PC, Settings>Connections:

  • Sync Protocol Listen Addresses: tcp4://127.0.0.1:22000
  • disabled global, local discovery, NAT traversal and relay.

On my phone (connected to wifi/local lan):

  • removed the connected device (hostPC) readded it: Replaced “dynamic” with tcp4://192.168.88.10:22000.

Unfortunately, the two devices are not connecting with each other.

Should I also change Sync Protocol Listen Addresses in Settings>SyncThing Options on my (Android) phone to this address?

I tried that, no success…

The log of hostPC shows both smartphones in a reconnect loop. BJ7SAQ4 is the phone that I made the change to static. The other device (another phone) I haven’t changed yet.

2020-04-05 16:16:33 My ID: WYNXQ6U-NVXIG6M-HEQVDTZ-MJYSJ76-TAJLVMZ-4RQALPY-NLJNPNA-RIZ4VAM
2020-04-05 16:16:34 Single thread SHA256 performance is 445 MB/s using minio/sha256-simd (387 MB/s using crypto/sha256).
2020-04-05 16:16:34 Hashing performance is 374.75 MB/s
2020-04-05 16:16:34 Overall send rate is unlimited, receive rate is unlimited
2020-04-05 16:16:34 TCP listener (127.0.0.1:22000) starting
2020-04-05 16:16:34 Ready to synchronize "Rud Signal" (vmnre-4yjw9) (sendreceive)
2020-04-05 16:16:34 Ready to synchronize "Rud's Pictures" (7zav9-3pz92) (sendreceive)
2020-04-05 16:16:34 Ready to synchronize "Shanti's pictures" (gm0py-swfrd) (sendreceive)
2020-04-05 16:16:34 Ready to synchronize "Shanti's Whatsapp" (gwgj0-5kke6) (sendreceive)
2020-04-05 16:16:34 Ready to synchronize "Rud's Whatsapp" (k2rik-qkoui) (sendreceive)
2020-04-05 16:16:34 ...
2020-04-05 16:16:34 Ready to synchronize "Shanti's Signal" (p0om1-9whzo) (sendreceive)
2020-04-05 16:16:34 GUI and API listening on [::]:8384
2020-04-05 16:16:34 Access the GUI via the following URL: http://127.0.0.1:8384/
2020-04-05 16:16:34 My name is "ServerPC"
2020-04-05 16:16:34 Device S3DNNDR-LBIDC5L-W7EN6YU-FNKTAIE-SUEDCUK-FNYYKGM-GEUXEPF-BJ7SAQ4 is "Rud's Pixel" at [dynamic]
2020-04-05 16:16:34 Device QCBIMQF-ECJ23VH-3E6KPP6-F4ZQ5IU-5E5RAJF-7CBZIPJ-47U6Q6U-HBUAXQ4 is "Shanti's Pixel" at [dynamic]
2020-04-05 16:16:34 Completed initial scan of sendreceive folder "Rud Signal" (vmnre-4yjw9)
2020-04-05 16:16:34 Completed initial scan of sendreceive folder "Rud's Whatsapp" (k2rik-qkoui)
2020-04-05 16:16:34 Completed initial scan of sendreceive folder "Shanti's Whatsapp" (gwgj0-5kke6)
2020-04-05 16:16:34 Completed initial scan of sendreceive folder "Shanti's Signal" (p0om1-9whzo)
2020-04-05 16:16:34 Completed initial scan of sendreceive folder "Shanti's pictures" (gm0py-swfrd)
2020-04-05 16:16:34 Completed initial scan of sendreceive folder "Rud's Pictures" (7zav9-3pz92)
2020-04-05 16:20:16 Enabled debug data for "protocol"
2020-04-05 16:20:20 Enabled debug data for "connections"
2020-04-05 16:20:37 Reconnect loop
2020-04-05 16:20:37 Reconnect loop for QCBIMQF-ECJ23VH-3E6KPP6-F4ZQ5IU-5E5RAJF-7CBZIPJ-47U6Q6U-HBUAXQ4 []
2020-04-05 16:20:37 Reconnect loop for S3DNNDR-LBIDC5L-W7EN6YU-FNKTAIE-SUEDCUK-FNYYKGM-GEUXEPF-BJ7SAQ4 []
2020-04-05 16:20:37 sleep until next dial 1m0s
2020-04-05 16:21:37 Reconnect loop
(...)
2020-04-05 16:44:37 sleep until next dial 1m0s
2020-04-05 16:44:49 deviceID: WYNXQ6U-NVXIG6M-HEQVDTZ-MJYSJ76-TAJLVMZ-4RQALPY-NLJNPNA-RIZ4VAM should be removed
2020-04-05 16:45:37 Reconnect loop
2020-04-05 16:45:37 Reconnect loop for QCBIMQF-ECJ23VH-3E6KPP6-F4ZQ5IU-5E5RAJF-7CBZIPJ-47U6Q6U-HBUAXQ4 []
2020-04-05 16:45:37 Reconnect loop for S3DNNDR-LBIDC5L-W7EN6YU-FNKTAIE-SUEDCUK-FNYYKGM-GEUXEPF-BJ7SAQ4 []
2020-04-05 16:45:37 sleep until next dial 1m0s

Also strange, device ..RIZ4VAM is the host itself, why is it reporting itself should be removed? Still something strange happening here

127.0.0.1 means only connections from local computer can happen. 0.0.0.0 means connections from anywhere can happen.

1 Like

That did the trick, thanks!

Although it connected yesterday and I successfully synced folders, I still get the reconnect loop messages in the log every second.

Also, today on my phone the log constantly says “connection refused”. I filled in the dyndns address (that worked perfectly yesterday): 1more.crabdance.com:22000 I checked if this port is open via: https://www.yougetsignal.com/tools/open-ports/

To get all of this working again: I change the server address on my phone to the local IP of the server 192.168.88.10:22000. The phone and host connect, start syncing. Now I disable wifi and fill in 1more.crabdance.com:22000 and magically, the phone and host connect and continue syncing…

What could be the problem here?

1more.crabdance.com is a CNAME forward to my mikrotik router address (that does the dynamic lookup).

Your OS dns cache or dyndns ttl is probably the issue. This is beyond syncthing at this point.

Luckily I use PiHole, I’ll find a way to fix it in there so that locally connected devices will get the IP.

Yeah I see that this question keeps coming up over the years - and I came looking here too, worried for the same reason. Maybe “I appear to be connected to myself … maybe because there is more than one device behind the same router”

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.