Nodes won't connect

I have set up two nodes, and am trying to share a directory called Test (with a single .pdf in it).

When I start syncthing on both machines, the output is the same:

syncthing
[AAAAA] 2014/04/29 11:58:48 INFO: syncthing v0.8.2 (go1.2.1 linux-amd64) jb@jborg-mbp 2014-04-27T06:35:23Z
[AAAAA] 2014/04/29 11:58:48 INFO: My ID:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[AAAAA] 2014/04/29 11:58:48 INFO: Starting web GUI on 127.0.0.1:8080/
[AAAAA] 2014/04/29 11:58:49 INFO: Populating repository index
[AAAAA] 2014/04/29 11:58:52 INFO: No UPnP IGD device found, no port mapping created (read udp4 0.0.0.0:35738: i/o timeout)
[AAAAA] 2014/04/29 11:58:52 INFO: Sending local discovery announcements
[AAAAA] 2014/04/29 11:58:52 INFO: Sending global discovery announcements
[AAAAA] 2014/04/29 11:58:52 OK: Ready to synchronize Test (read-write)

The same for machine BBBBB. Both nodes are on the LAN. The directories never synch and the GUI always says “disconnected”.

The config for both is simple:

<configuration version="2">
    <repository id="Test" directory="/home/ed/Test" ro="false">
    <node id="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" name="Box1">
        <address>dynamic
    </node>
    <node id="BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB" name="Box2">
        <address>dynamic
    </node>
    </repository>
    <gui enabled="true">
        <address>127.0.0.1:8080
    </gui>
    <options>
        <listenAddress>:22000
        <globalAnnounceServer>announce.syncthing.net:22025
        <globalAnnounceEnabled>true
        <localAnnounceEnabled>true
        <parallelRequests>16
        <maxSendKbps>0
        <rescanIntervalS>60
        <reconnectionIntervalS>60
        <maxChangeKbps>1000
        <startBrowser>false
        <upnpEnabled>true
    </options>
</configuration>

I have tried opening 22000 in the firewall for TCP connections, no dice.

I tried creating the configs manually, as well as deleting everything and just using the GUI: same result. Except when doing it manually, as in the example in the Case Study, the nodes don’t appear to each other at all (probably the version mismatch at work there).

What am I missing?

Edit

This is definitely related to the UPnP error on startup: No UPnP IGD device found, no port mapping created (read udp4 0.0.0.0:35738: i/o timeout)

If I change from dynamic discovery to using the boxes IP addresses, then everything works fine.

How do I get UPnP working properly? It is enabled in my configs, why is it failing?

If the two boxes are on the same LAN, UPnP will not be necessary. However, both the local node discovery (used when the address is set to “dynamic”) and the UPnP discovery uses IPv4 multicast. This is sometimes not available, in certain wireless networks etc. Posting some output from running STTRACE=discover syncthing might give some clues, but I expect that the discovery packets from one node simply don’t reach the other node.

Thanks calmh.

The nodes are connected over ethernet. In the LAN scenarion, should’nt I be able to disable global discovery? If I do that, each node reports as “offline”.

This is some of the output using the discover variable:

STTRACE=discover syncthing                                                                                                                                
[AAAAA] 2014/04/30 10:11:03 INFO: syncthing v0.8.2 (go1.2.1 linux-amd64) jb@jborg-mbp 2014-04-27T06:35:23Z
[AAAAA] 2014/04/30 10:11:03 INFO: My ID: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
[AAAAA] 2014/04/30 10:11:03 INFO: Starting web GUI on http://127.0.0.1:8484/
[AAAAA] 2014/04/30 10:11:03 INFO: Populating repository index
[AAAAA] 2014/04/30 10:11:06 INFO: No UPnP IGD device found, no port mapping created (read udp4 0.0.0.0:57946: i/o timeout)
[AAAAA] 2014/04/30 10:11:06 INFO: Sending local discovery announcements
[AAAAA] 2014/04/30 10:11:06 INFO: Sending global discovery announcements
[AAAAA] 2014/04/30 10:11:06 OK: Ready to synchronize Test (read-write)
discover: 10:11:06.537821 discover.go:87: announcing :22000: &net.TCPAddr{IP:net.IP{}, Port:22000, Zone:""}
discover: 10:11:06.539563 discover.go:188: read announcement:
00000000  02 9e 4c 77 00 00 00 34  47 42 4a 35 34 32 4a 49  |..Lw...AAAAAAAAA|
00000010  56 4b 4a 37 43 49 46 55  53 48 4d 44 58 4e 51 36  |AAAAAAAAAAAAAAAA|
00000020  33 33 54 48 35 58 33 4c  34 54 41 41 48 57 49 35  |AAAAAAAAAAAAAAAA|
00000030  4c 56 44 4b 45 56 4f 55  51 34 4e 41 00 00 00 01  |AAAAAAAAAAAA....|
00000040  00 00 00 00 5e b2 00 00                           |....^...|
discover: 10:11:06.539845 discover.go:198: parsed announcement: discover.AnnounceV2{Magic:0x29e4c77, NodeID:"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", Addresses:[]discover.Address{discover.Address{IP:[]uint8{}, Port:0x5eb2}}}
discover: 10:11:06.539976 discover.go:188: read announcement:
00000000  02 9e 4c 77 00 00 00 34  47 42 4a 35 34 32 4a 49  |..Lw...AAAAAAAAA|
00000010  56 4b 4a 37 43 49 46 55  53 48 4d 44 58 4e 51 36  |AAAAAAAAAAAAAAAA|
00000020  33 33 54 48 35 58 33 4c  34 54 41 41 48 57 49 35  |AAAAAAAAAAAAAAAA|
00000030  4c 56 44 4b 45 56 4f 55  51 34 4e 41 00 00 00 01  |AAAAAAAAAAAA....|
00000040  00 00 00 00 5e b2 00 00                           |....^...|
discover: 10:11:06.540118 discover.go:198: parsed announcement: discover.AnnounceV2{Magic:0x29e4c77, NodeID:"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", Addresses:[]discover.Address{discover.Address{IP:[]uint8{}, Port:0x5eb2}}}
discover: 10:11:06.540219 discover.go:188: read announcement:
00000000  02 9e 4c 77 00 00 00 34  47 42 4a 35 34 32 4a 49  |..Lw...AAAAAAAAA|
00000010  56 4b 4a 37 43 49 46 55  53 48 4d 44 58 4e 51 36  |AAAAAAAAAAAAAAAA|
00000020  33 33 54 48 35 58 33 4c  34 54 41 41 48 57 49 35  |AAAAAAAAAAAAAAAA|
00000030  4c 56 44 4b 45 56 4f 55  51 34 4e 41 00 00 00 01  |AAAAAAAAAAAA....|
00000040  00 00 00 00 5e b2 00 00                           |....^...|
discover: 10:11:06.540359 discover.go:198: parsed announcement: discover.AnnounceV2{Magic:0x29e4c77, NodeID:"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", Addresses:[]discover.Address{discover.Address{IP:[]uint8{}, Port:0x5eb2}}}
discover: 10:11:06.541088 discover.go:87: announcing :22000: &net.TCPAddr{IP:net.IP{}, Port:22000, Zone:""}
discover: 10:11:06.541241 discover.go:148: send announcement -> 194.126.249.5:22025
00000000  02 9e 4c 77 00 00 00 34  47 42 4a 35 34 32 4a 49  |..Lw...AAAAAAAAA|
00000010  56 4b 4a 37 43 49 46 55  53 48 4d 44 58 4e 51 36  |AAAAAAAAAAAAAAAA|
00000020  33 33 54 48 35 58 33 4c  34 54 41 41 48 57 49 35  |AAAAAAAAAAAAAAAA|
00000030  4c 56 44 4b 45 56 4f 55  51 34 4e 41 00 00 00 01  |AAAAAAAAAAAA....|
00000040  00 00 00 00 5e b2 00 00                           |....^...|
discover: 10:11:07.847969 discover.go:272: read external:
00000000  02 9e 4c 77 00 00 00 34  47 42 4a 35 34 32 4a 49  |..Lw...AAAAAAAAA|
00000010  56 4b 4a 37 43 49 46 55  53 48 4d 44 58 4e 51 36  |AAAAAAAAAAAAAAAA|
00000020  33 33 54 48 35 58 33 4c  34 54 41 41 48 57 49 35  |AAAAAAAAAAAAAAAA|
00000030  4c 56 44 4b 45 56 4f 55  51 34 4e 41 00 00 00 01  |AAAAAAAAAAAA....|
00000040  00 00 00 04 ca 4e f0 07  5e b2 00 00              |.....N..^...|
discover: 10:11:07.848164 discover.go:283: parsed external: discover.AnnounceV2{Magic:0x29e4c77, NodeID:"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", Addresses:[]discover.Address{discover.Address{IP:[]uint8{0xca, 0x4e, 0xf0, 0x7}, Port:0x5eb2}}}
discover: 10:11:07.848302 discover.go:164: external lookup check: [202.78.240.7:22000]
discover: 10:11:36.538256 discover.go:188: read announcement:
00000000  02 9e 4c 77 00 00 00 34  47 42 4a 35 34 32 4a 49  |..Lw...AAAAAAAAA|
00000010  56 4b 4a 37 43 49 46 55  53 48 4d 44 58 4e 51 36  |AAAAAAAAAAAAAAAA|
00000020  33 33 54 48 35 58 33 4c  34 54 41 41 48 57 49 35  |AAAAAAAAAAAAAAAA|
00000030  4c 56 44 4b 45 56 4f 55  51 34 4e 41 00 00 00 01  |AAAAAAAAAAAA....|
00000040  00 00 00 00 5e b2 00 00                           |....^...|
discover: 10:11:36.538417 discover.go:198: parsed announcement: discover.AnnounceV2{Magic:0x29e4c77, NodeID:"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", Addresses:[]discover.Address{discover.Address{IP:[]uint8{}, Port:0x5eb2}}}
discover: 10:11:36.538498 discover.go:188: read announcement:
00000000  02 9e 4c 77 00 00 00 34  47 42 4a 35 34 32 4a 49  |..Lw...AAAAAAAAA|
00000010  56 4b 4a 37 43 49 46 55  53 48 4d 44 58 4e 51 36  |AAAAAAAAAAAAAAAA|
00000020  33 33 54 48 35 58 33 4c  34 54 41 41 48 57 49 35  |AAAAAAAAAAAAAAAA|
00000030  4c 56 44 4b 45 56 4f 55  51 34 4e 41 00 00 00 01  |AAAAAAAAAAAA....|
00000040  00 00 00 00 5e b2 00 00                           |....^...|
discover: 10:11:36.538723 discover.go:198: parsed announcement: discover.AnnounceV2{Magic:0x29e4c77, NodeID:"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", Addresses:[]discover.Address{discover.Address{IP:[]uint8{}, Port:0x5eb2}}}
discover: 10:11:36.538804 discover.go:188: read announcement:
00000000  02 9e 4c 77 00 00 00 34  47 42 4a 35 34 32 4a 49  |..Lw...AAAAAAAAA|
00000010  56 4b 4a 37 43 49 46 55  53 48 4d 44 58 4e 51 36  |AAAAAAAAAAAAAAAA|
00000020  33 33 54 48 35 58 33 4c  34 54 41 41 48 57 49 35  |AAAAAAAAAAAAAAAA|
00000030  4c 56 44 4b 45 56 4f 55  51 34 4e 41 00 00 00 01  |AAAAAAAAAAAA....|
00000040  00 00 00 00 5e b2 00 00                           |....^...|
discover: 10:17:36.538818 discover.go:198: parsed announcement: discover.AnnounceV2{Magic:0x29e4c77, NodeID:"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", Addresses:[]discover.Address{discover.Address{IP:[]uint8{}, Port:0x5eb2}}}

Also included here as it is easier to read.

Seems I can only use this on my LAN without dynamic addresses, which doesn’t seem right.

Assuming that “AAAAA…” stands for the same thing everywhere (there’s no need to do this… the node ID is not sensitive and I wouldn’t have put it front and center in the logs if it were :wink:) it seems like they indeed cannot see each other’s announcements. I can’t see any reason for this other than IP multicast being blocked by your switch.

You are correct in that you don’t need to have global discovery enabled. I see that the red “Offline” pops up when global discovery is disabled. That’s a bug (issue 167 now).

Actually, you know what, there seems to be something crappy going on here with the local discovery. Let me make some investigations…

Edit: No, I was fooling myself. Works for me between Mac and a Linux VM, with wireless etc inbetween. :confused:

Good to know my paranoia was misplaced :smile:

This is puzzling. My router has Multicast proxy and IGMP snooping enabled (standard mode) and the nics of the nodes show multicast as up: yet with both Global and Local discovery enabled on both nodes, the output with STTRACE="net" shows syncthing trying to connect to the external IP addresses and so getting “connection refused” responses.

I could forward that port, but wouldn’t it be better to have syncthing use the LAN address? Can I force that (using dynamic, not setting IP:port directly in the config)?

It tries to connect to the external address because that’s what it gets back from the global discovery server, which it uses because the local announce isn’t working for some reason.

Can you run tcpdump on one or both of your nodes? If you run something like tcpdump -n -i en0 -X port 21025 with en0 being whatever interface is the LAN interface on your computer, you should see discovery packets every 30 seconds. If everything works correctly, the output should be something like this:

08:04:02.303184 IP 172.16.32.207.21025 > 239.21.0.25.21025: UDP, length 72
	0x0000:  4500 0064 e31b 0000 0111 1a60 ac10 20cf  E..d.......`....
	0x0010:  ef15 0019 5221 5221 0050 9986 029e 4c77  ....R!R!.P....Lw
	0x0020:  0000 0034 4c35 374b 494c 474b 4843 4a44  ...4L57KILGKHCJD
	0x0030:  4356 584c 4c32 4c4c 4e4c 4a48 5741 4f34  CVXLL2LLNLJHWAO4
	0x0040:  4155 4353 3353 5652 4437 4d47 4c4e 3256  AUCS3SVRD7MGLN2V
	0x0050:  5a34 4137 4943 4351 0000 0001 0000 0000  Z4A7ICCQ........
	0x0060:  55f0 0000                                U...
08:04:12.480363 IP 172.16.32.25.21025 > 239.21.0.25.21025: UDP, length 72
	0x0000:  4500 0064 00ab 4000 0111 bd86 ac10 2019  E..d..@.........
	0x0010:  ef15 0019 5221 5221 0050 4cf6 029e 4c77  ....R!R!.PL...Lw
	0x0020:  0000 0034 4e46 474b 454b 4537 5a36 5254  ...4NFGKEKE7Z6RT
	0x0030:  4849 3350 525a 5853 4445 4a46 3355 4652  HI3PRZXSDEJF3UFR
	0x0040:  574a 4246 4f56 4242 5444 4e34 5347 4e47  WJBFOVBBTDN4SGNG
	0x0050:  565a 5155 5148 4a41 0000 0001 0000 0000  VZQUQHJA........
	0x0060:  55f0 0000                                U...

That is one announce packet from 172.16.32.207 for L57KIL…etc and one from 172.16.32.25 for NFGKE…etc. You should definitely see your own announcement packets going out. If you also see announcement packets from other nodes, things are working properly network wise and there must be a bug in syncthing.

I suspect that you’ll see your discovery packets going out, but not packets from other nodes. If that situation is the same on both nodes, something is eating the discovery packets…

OK: there is definitely something wrong. For Machine A, it sees announce packets only for B:

19:31:37.243186 IP 192.168.1.80.21025 > 239.21.0.25.21025: UDP, length 72
        0x0000:  4500 0064 23ff 4000 0111 a3eb c0a8 01c8  E..d#.@.........
        0x0010:  ef15 0019 5221 5221 0050 d9f1 029e 4c77  ....R!R!.P....Lw
        0x0020:  0000 0034 4d36 4836 3257 5a4b 444c 4757  ...4JUTR87GREFT
etc...

Machine B sees only packets for itself:

19:31:37.230476 IP 192.168.1.200.21025 > 239.21.0.25.21025: UDP, length 72
        0x0000:  4500 0064 23ff 4000 0111 a3eb c0a8 01c8  E..d#.@.........
        0x0010:  ef15 0019 5221 5221 0050 b200 029e 4c77  ....R!R!.P....Lw
        0x0020:  0000 0034 4d36 4836 3257 5a4b 444c 4757  ...4JUTR87GREFT
etc...

The firewalls rules are the same for both machines, allowing everything from 192.168.1.0/24.

Thanks for perservering with me on this: this sort of networking voodoo is well outside my comfort zone.

Checking open ports on Machine A:

lsof -i tcp -i udp
COMMAND   PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
syncthing 442 ed    3u  IPv4 164077      0t0  UDP *:21025 
syncthing 442 ed    4u  IPv4 164079      0t0  UDP *:21025 
syncthing 442 ed    5u  IPv6 166387      0t0  UDP *:37692 
syncthing 442 ed    6u  IPv6 164082      0t0  TCP *:filesphere (LISTEN)
syncthing 442 ed    8u  IPv4 167145      0t0  TCP localhost.localdomain:8484 (LISTEN)

and Machine B:

lsof -i tcp -i udp
COMMAND   PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
syncthing  9446 ed    3u  IPv4 29896239      0t0  UDP *:21025 
syncthing  9446 ed    4u  IPv4 29895429      0t0  TCP localhost:8484 (LISTEN)
syncthing  9446 ed    6u  IPv6 29895469      0t0  TCP *:24242 (LISTEN)
syncthing  9446 ed    7u  IPv6 29896245      0t0  UDP *:46266 
syncthing  9446 ed    8u  IPv4 29896241      0t0  UDP *:21025 
syncthing  9446 ed    9u  IPv4 29896243      0t0  UDP *:21025 
syncthing  9446 ed   1u  IPv4 29918526      0t0  TCP 10.122.1.6:38862->XXX.XXX.XXX.XXX.my.isp.net:24242 (SYN_SENT)

Hmm. Weird. So it seems machine B is working, so far as it’s sending announcements and they reach machine A. Machine A either doesn’t send announcements or they are firewalled. Unfortunately the available debugging in v0.8.2 is a little bit crappy. Could you upgrade machine A to the latest development build (binary below) and run it as STTRACE=mc,discover syncthing to get more info on if it thinks it’s sending packets and so on? Correlating that with a tcpdump on machine A would be interesting…

https://nym.se/t/syncthing-linux-amd64-v0.8.2-20-g0ae3426.tar.gz

Are these traces correct or a copypaste-o? It looks like both 192.168.1.80 and 192.168.1.200 are announcing the node ID JUTR87…? They should have different keys, hence different node IDs.

This is Machine A using 2-20:

[KTZTV] 2014/05/02 21:45:00 INFO: Restarting
[KTZTV] 2014/05/02 21:45:02 INFO: syncthing v0.8.2-20-g0ae3426 (go1.2.1 linux-amd64) jb@jborg-mbp 2014-05-02T09:04:56Z
[KTZTV] 2014/05/02 21:45:02 INFO: My ID: KTZTVOHVATS7VLUGFFRWVFRJB7HL3DUTI77BJJDUFS7BK3NJRCNA
[KTZTV] 2014/05/02 21:45:02 INFO: Starting web GUI on http://127.0.0.1:8484/
[KTZTV] 2014/05/02 21:45:02 INFO: Populating repository index
[KTZTV] 2014/05/02 21:45:05 INFO: No UPnP IGD device found, no port mapping created (read udp4 0.0.0.0:52507: i/o timeout)
[KTZTV] 2014/05/02 21:45:05 INFO: Sending global discovery announcements
[KTZTV] 2014/05/02 21:45:05 OK: Ready to synchronize Test (read-write)
mc: 21:45:05.357241 beacon.go:49: trying 2 interfaces
mc: 21:45:05.357520 beacon.go:56: trying interface "lo"
mc: 21:45:05.357664 beacon.go:66: listening for multicast group on "lo"
mc: 21:45:05.357722 beacon.go:56: trying interface "enp2s0"
mc: 21:45:05.357863 beacon.go:66: listening for multicast group on "enp2s0"
discover: 21:45:05.391794 discover.go:100: announcing :24242: &net.TCPAddr{IP:net.IP{}, Port:24242, Zone:""}
discover: 21:45:05.391861 discover.go:161: send announcement -> 194.126.249.5:22025
00000000  02 9e 4c 77 00 00 00 34  4b 54 5a 54 56 4f 48 56  |..Lw...4KTZTVOHV|
00000010  41 54 53 37 56 4c 55 47  46 46 52 57 56 46 52 4a  |ATS7VLUGFFRWVFRJ|
00000020  42 37 48 4c 33 44 55 54  49 37 37 42 4a 4a 44 55  |B7HL3DUTI77BJJDU|
00000030  46 53 37 42 4b 33 4e 4a  52 43 4e 41 00 00 00 01  |FS7BK3NJRCNA....|
00000040  00 00 00 00 5e b2 00 00                           |....^...|
discover: 21:45:06.791246 discover.go:285: read external:
00000000  02 9e 4c 77 00 00 00 34  4b 54 5a 54 56 4f 48 56  |..Lw...4KTZTVOHV|
00000010  41 54 53 37 56 4c 55 47  46 46 52 57 56 46 52 4a  |ATS7VLUGFFRWVFRJ|
00000020  42 37 48 4c 33 44 55 54  49 37 37 42 4a 4a 44 55  |B7HL3DUTI77BJJDU|
00000030  46 53 37 42 4b 33 4e 4a  52 43 4e 41 00 00 00 01  |FS7BK3NJRCNA....|
00000040  00 00 00 04 cb 56 cf f1  5e b2 00 00              |.....V..^...|
discover: 21:45:06.791349 discover.go:296: parsed external: discover.AnnounceV2{Magic:0x29e4c77, NodeID:"KTZTVOHVATS7VLUGFFRWVFRJB7HL3DUTI77BJJDUFS7BK3NJRCNA", Addresses:[]discover.Address{discover.Address{IP:[]uint8{0xcb, 0x56, 0xcf, 0xf1}, Port:0x5eb2}}}
discover: 21:45:06.791405 discover.go:177: external lookup check: [XXX.XXX.XXX.XXX:24242]
discover: 21:45:10.946963 discover.go:285: read external:
00000000  02 9e 4c 77 00 00 00 34  4d 36 48 36 32 57 5a 4b  |..Lw...4JUTR87GR|
00000010  44 4c 47 57 4f 37 45 49  4a 43 48 46 59 57 45 58  |EFTWO7EIJCHFYWEX|
00000020  45 4c 54 32 4d 52 4d 48  4d 50 35 58 49 52 47 36  |ELT2MRMHMP5XIRG6|
00000030  33 4b 37 49 32 48 37 52  42 57 50 41 00 00 00 01  |3K7I2H7RBWPA....|
00000040  00 00 00 04 b3 2b 85 62  5e b2 00 00              |.....+.b^...|
discover: 21:45:10.947045 discover.go:296: parsed external: discover.AnnounceV2{Magic:0x29e4c77, NodeID:"JUTR87GREFTWO7EIJCHFYWEXELT2MRMHMP5XIRG63K7I2H7RBWPA", Addresses:[]discover.Address{discover.Address{IP:[]uint8{0xb3, 0x2b, 0x85, 0x62}, Port:0x5eb2}}}
discover: 21:46:16.794089 discover.go:285: read external:
00000000  02 9e 4c 77 00 00 00 34  4d 36 48 36 32 57 5a 4b  |..Lw...4JUTR87GR|
00000010  44 4c 47 57 4f 37 45 49  4a 43 48 46 59 57 45 58  |EFTWO7EIJCHFYWEX|
00000020  45 4c 54 32 4d 52 4d 48  4d 50 35 58 49 52 47 36  |ELT2MRMHMP5XIRG6|
00000030  33 4b 37 49 32 48 37 52  42 57 50 41 00 00 00 01  |3K7I2H7RBWPA....|
00000040  00 00 00 04 b3 2b 85 62  5e b2 00 00              |.....+.b^...|
discover: 21:46:16.794163 discover.go:296: parsed external: discover.AnnounceV2{Magic:0x29e4c77, NodeID:"JUTR87GREFTWO7EIJCHFYWEXELT2MRMHMP5XIRG63K7I2H7RBWPA", Addresses:[]discover.Address{discover.Address{IP:[]uint8{0xb3, 0x2b, 0x85, 0x62}, Port:0x5eb2}}}

And the tcpdumpfrom A while that was running:

21:45:08.394828 IP 192.168.1.200.21025 > 239.21.0.25.21025: UDP, length 72
        0x0000:  4500 0064 23f6 4000 0111 a3f4 c0a8 01c8  E..d#.@.........
        0x0010:  ef15 0019 5221 5221 0050 d9f1 029e 4c77  ....R!R!.P....Lw
        0x0020:  0000 0034 4d36 4836 3257 5a4b 444c 4757  ...4JUTR87GREFTW
        0x0030:  4f37 4549 4a43 4846 5957 4558 454c 5432  O7EIJCHFYWEXELT2
        0x0040:  4d52 4d48 4d50 3558 4952 4736 334b 3749  MRMHMP5XIRG63K7I
        0x0050:  3248 3752 4257 5041 0000 0001 0000 0000  2H7RBWPA........
        0x0060:  5eb2 0000                                ^...
21:45:38.394941 IP 192.168.1.200.21025 > 239.21.0.25.21025: UDP, length 72
        0x0000:  4500 0064 23f9 4000 0111 a3f1 c0a8 01c8  E..d#.@.........
        0x0010:  ef15 0019 5221 5221 0050 d9f1 029e 4c77  ....R!R!.P....Lw
        0x0020:  0000 0034 4d36 4836 3257 5a4b 444c 4757  ...4JUTR87GREFTW
        0x0030:  4f37 4549 4a43 4846 5957 4558 454c 5432  O7EIJCHFYWEXELT2
        0x0040:  4d52 4d48 4d50 3558 4952 4736 334b 3749  MRMHMP5XIRG63K7I
        0x0050:  3248 3752 4257 5041 0000 0001 0000 0000  2H7RBWPA........
        0x0060:  5eb2 0000                                ^...
21:46:08.394949 IP 192.168.1.200.21025 > 239.21.0.25.21025: UDP, length 72
        0x0000:  4500 0064 23fc 4000 0111 a3ee c0a8 01c8  E..d#.@.........
        0x0010:  ef15 0019 5221 5221 0050 d9f1 029e 4c77  ....R!R!.P....Lw
        0x0020:  0000 0034 4d36 4836 3257 5a4b 444c 4757  ...4JUTR87GREFTW
        0x0030:  4f37 4549 4a43 4846 5957 4558 454c 5432  O7EIJCHFYWEXELT2
        0x0040:  4d52 4d48 4d50 3558 4952 4736 334b 3749  MRMHMP5XIRG63K7I
        0x0050:  3248 3752 4257 5041 0000 0001 0000 0000  2H7RBWPA........
        0x0060:  5eb2 0000                                ^...

Sorry: I obviously screwed up the pasting :frowning:

So, you’ve disabled local discovery on machine A…?

Only because I am an idiot. Sorry for that.

Machine A with local discovery on is pasted here and the tcpdump is here.

OK, that makes sense (for the problem at hand) - outgoing announcement are going out, incoming announcements are coming in so that tcpdump sees them, but syncthing doesn’t see that. That would seem like either a bug, or a firewall rule. Is the firewall enabled? I could imagine multicast not being covered by the default rules, so if so disabling that would be a good start. But I’ll look into reproducing this, in case there is some Linux-specific multicast issue in syncthing…

It’s likely a firewall rule. I had tried opening multicast ports (1900,1901) and that made no difference. I just disabled both firewalls and local discovery worked. I’m sorry: I should have tried that earlier and avoided this mess.

My rules are currently here. What port(s) do I need open for syncthing’s local discovery to work?

This was what I needed:

# ufw allow from 192.168.1.0/24 to 224.0.0.0/3 proto udp

Thanks for your help and pateince!

Yep. You could probably get away with only allowing port 21025 to 239.21.0.25. The underlying issue is probably that since it’s unidirectional multicast, there isn’t a “connection” or flow established that would be allowed by normal “allow return traffic” rules.

I’m using syncthing in Android 0.9.0 and beta9 on the desktop and they are not able to connect, the wifi is in a different subnet.

I can reach synthing port 22000 from the desktop with nmap and see it open. What could be the problem? Shouldn’t it be able to find the local address through the announce server also?

No. Local addresses are not exposed to the announce server and local discovery only works within a subnet. In this case you’ll need to manually configure the address of one node on the other.

We could fix this by sending local addresses also for discovery, would you accept a patch for that see any problem with this approach?

In general, local addresses are not useful for connecting to a node from the “outside”. Also, I’m not sure people in general would expect that information to be exposed. So no, I don’t think this is suitable in the standard case. Those cases where you have multiple subnets behind a firewall are more advanced and can be handled by manual configuration or a custom announce server.