discosrv, IPv6, and "multicast listener report v2"

Support
1

First of fall, thank you very much for this great piece of software. After some fiddling I finally managed to get syncthing and syncthing-discosrv running on FreeBSD. Both run in a jail that only has an IPv6 address. I have two concerns

  1. While trying different setups to make the syncthing instance on the server itself discover the discosrv instance on the same machine I finally managed discovery by setting the IPv6 address explicitly in the settings. Using the domain name does not work. Why not? Is there any possibility to make this possible? IPv6 addresses aren’t quite handy, you know. :smile:

  2. Additionally, I discovered the following packages being blocked by my PF firewall. And I do not understand what it is and why it is happening. :blush:

    00:00:05.867860 rule 0..16777216/0(match): block out on re0: (hlim 1, next-header Options (0) payload length: 36) fe80::6e62:6dff:fe60:74fb > ff02::16: HBH (padn)(rtalert: 0x0000) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff32::5222 to_ex, 0 source(s)]

The global announce server is discovered though. I opened ports 8080, 22000, 21025, 22026. Yet my PF firewall settings are quite strict. I just let pass icmp6-type traffic 1 2 3 4 128 129 131 133 134 135 136. I guess that I need to open another one to allow above packages to go through, too. But I do not know which ones – knowledge about this level of networking I do not have, unfortunately. Are these packages important?

I am not 100% sure that they derive from syncthing but most probably: they always appear once I restart the syncthing server.

Update: I guess something is still not working since my client in my LAN is able to discover the global announce server as well as the syncthing instance on the server but it’s not uploading any data. Any help is very much appreciated.

2

Re 1. Does the name resolve to a v6 address? Or both v6 and v4?

Re 2. Not sure we don’t rely on icmp packets afaik. Perhaps it’s the os dns library checking which A record is alive?

Re update. Run syncthing with STTRACE=discovery and discosrv with -debug to see if announcements and lookups are happening.

3

First of all, please excuse such a late reply. I was quite busy the last weeks and had to update to FreeBSD 10.1 before I wanted to solve the problems mentioned above.

The client detects the server with the following log messages. After that the output remains silent.

[CIMFT] 23:57:11 INFO: Device <ID> client is "syncthing v0.10.12"
[CIMFT] 23:57:11 INFO: Device <ID> name is "<DOMAIN>"

The server is much more verbose outputting a lot of things I do not understand:

$ sudo -u syncthing syncthing-discosrv -debug 
2015/03/16 22:54:20 New limiter for <CLIENT-IP>
2015/03/16 22:54:20 <- [<CLIENT-IP>]:54320 discover.Announce{Magic:0x9d79bc39, This:discover.Device{ID:[]uint8{0x12, 0x18, 0x59, 0xd0, 0xe6, 0x42, 0xb7, 0x1b, 0x15, 0x7, 0x91, 0xfa, 0xde, 0xf2, 0x91, 0x5d, 0xcb, 0x56, 0xf, 0x12, 0x5d, 0x95, 0x42, 0x1, 0xfc, 0x2e, 0x7e, 0x94, 0x49, 0xe5, 0x22, 0x4c}, Addresses:[]discover.Address{discover.Address{IP:[]uint8(nil), Port:0x55f0}}}, Extra:[]discover.Device{}}
2015/03/16 22:54:21 <- [<CLIENT-IP>]:34638 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0x12, 0x18, 0x59, 0xd0, 0xe6, 0x42, 0xb7, 0x1b, 0x15, 0x7, 0x91, 0xfa, 0xde, 0xf2, 0x91, 0x5d, 0xcb, 0x56, 0xf, 0x12, 0x5d, 0x95, 0x42, 0x1, 0xfc, 0x2e, 0x7e, 0x94, 0x49, 0xe5, 0x22, 0x4c}}
2015/03/16 22:54:21 -> [<CLIENT-IP>]:34638 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0x12, 0x18, 0x59, 0xd0, 0xe6, 0x42, 0xb7, 0x1b, 0x15, 0x7, 0x91, 0xfa, 0xde, 0xf2, 0x91, 0x5d, 0xcb, 0x56, 0xf, 0x12, 0x5d, 0x95, 0x42, 0x1, 0xfc, 0x2e, 0x7e, 0x94, 0x49, 0xe5, 0x22, 0x4c}}
2015/03/16 22:54:24 New limiter for <SERVER-IP>
2015/03/16 22:54:24 <- [<SERVER-IP>]:32768 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0x12, 0x18, 0x59, 0xd0, 0xe6, 0x42, 0xb7, 0x1b, 0x15, 0x7, 0x91, 0xfa, 0xde, 0xf2, 0x91, 0x5d, 0xcb, 0x56, 0xf, 0x12, 0x5d, 0x95, 0x42, 0x1, 0xfc, 0x2e, 0x7e, 0x94, 0x49, 0xe5, 0x22, 0x4c}}
2015/03/16 22:54:24 -> [<SERVER-IP>]:32768 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0x12, 0x18, 0x59, 0xd0, 0xe6, 0x42, 0xb7, 0x1b, 0x15, 0x7, 0x91, 0xfa, 0xde, 0xf2, 0x91, 0x5d, 0xcb, 0x56, 0xf, 0x12, 0x5d, 0x95, 0x42, 0x1, 0xfc, 0x2e, 0x7e, 0x94, 0x49, 0xe5, 0x22, 0x4c}}
2015/03/16 22:54:52 <- [<CLIENT-IP>]:33804 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0x18, 0x49, 0x78, 0x3d, 0xd, 0xe9, 0x42, 0xaa, 0x1d, 0x70, 0x36, 0x8b, 0x7, 0xa2, 0x30, 0xb0, 0xc8, 0xc6, 0x20, 0x3f, 0x83, 0x68, 0xa5, 0x72, 0x72, 0x93, 0xe8, 0x81, 0xa3, 0x75, 0x87, 0x79}}
2015/03/16 22:54:57 <- [<CLIENT-IP>]:39408 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0xe7, 0x7f, 0x85, 0x96, 0xc5, 0x3b, 0x8c, 0x99, 0x95, 0x78, 0x71, 0xbc, 0xc8, 0x1f, 0x75, 0xe7, 0xb4, 0x9c, 0x27, 0xa7, 0x7f, 0xbf, 0xe8, 0xf6, 0xe, 0x24, 0x27, 0xa4, 0x95, 0xec, 0x31, 0xd6}}
2015/03/16 22:54:57 -> [<CLIENT-IP>]:39408 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0xe7, 0x7f, 0x85, 0x96, 0xc5, 0x3b, 0x8c, 0x99, 0x95, 0x78, 0x71, 0xbc, 0xc8, 0x1f, 0x75, 0xe7, 0xb4, 0x9c, 0x27, 0xa7, 0x7f, 0xbf, 0xe8, 0xf6, 0xe, 0x24, 0x27, 0xa4, 0x95, 0xec, 0x31, 0xd6}}
2015/03/16 22:55:29 <- [<CLIENT-IP>]:40904 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0x18, 0x49, 0x78, 0x3d, 0xd, 0xe9, 0x42, 0xaa, 0x1d, 0x70, 0x36, 0x8b, 0x7, 0xa2, 0x30, 0xb0, 0xc8, 0xc6, 0x20, 0x3f, 0x83, 0x68, 0xa5, 0x72, 0x72, 0x93, 0xe8, 0x81, 0xa3, 0x75, 0x87, 0x79}}
2015/03/16 22:56:34 <- [<CLIENT-IP>]:40252 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0x18, 0x49, 0x78, 0x3d, 0xd, 0xe9, 0x42, 0xaa, 0x1d, 0x70, 0x36, 0x8b, 0x7, 0xa2, 0x30, 0xb0, 0xc8, 0xc6, 0x20, 0x3f, 0x83, 0x68, 0xa5, 0x72, 0x72, 0x93, 0xe8, 0x81, 0xa3, 0x75, 0x87, 0x79}}
2015/03/16 22:57:39 <- [<CLIENT-IP>]:44979 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0x18, 0x49, 0x78, 0x3d, 0xd, 0xe9, 0x42, 0xaa, 0x1d, 0x70, 0x36, 0x8b, 0x7, 0xa2, 0x30, 0xb0, 0xc8, 0xc6, 0x20, 0x3f, 0x83, 0x68, 0xa5, 0x72, 0x72, 0x93, 0xe8, 0x81, 0xa3, 0x75, 0x87, 0x79}}
2015/03/16 22:58:44 <- [<CLIENT-IP>]:37425 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0x18, 0x49, 0x78, 0x3d, 0xd, 0xe9, 0x42, 0xaa, 0x1d, 0x70, 0x36, 0x8b, 0x7, 0xa2, 0x30, 0xb0, 0xc8, 0xc6, 0x20, 0x3f, 0x83, 0x68, 0xa5, 0x72, 0x72, 0x93, 0xe8, 0x81, 0xa3, 0x75, 0x87, 0x79}}
2015/03/16 22:59:49 <- [<CLIENT-IP>]:40146 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0x18, 0x49, 0x78, 0x3d, 0xd, 0xe9, 0x42, 0xaa, 0x1d, 0x70, 0x36, 0x8b, 0x7, 0xa2, 0x30, 0xb0, 0xc8, 0xc6, 0x20, 0x3f, 0x83, 0x68, 0xa5, 0x72, 0x72, 0x93, 0xe8, 0x81, 0xa3, 0x75, 0x87, 0x79}}
2015/03/16 23:00:54 <- [<CLIENT-IP>]:43289 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0x18, 0x49, 0x78, 0x3d, 0xd, 0xe9, 0x42, 0xaa, 0x1d, 0x70, 0x36, 0x8b, 0x7, 0xa2, 0x30, 0xb0, 0xc8, 0xc6, 0x20, 0x3f, 0x83, 0x68, 0xa5, 0x72, 0x72, 0x93, 0xe8, 0x81, 0xa3, 0x75, 0x87, 0x79}}
2015/03/16 23:01:59 <- [<CLIENT-IP>]:37421 discover.Query{Magic:0x2ca856f5, DeviceID:[]uint8{0x18, 0x49, 0x78, 0x3d, 0xd, 0xe9, 0x42, 0xaa, 0x1d, 0x70, 0x36, 0x8b, 0x7, 0xa2, 0x30, 0xb0, 0xc8, 0xc6, 0x20, 0x3f, 0x83, 0x68, 0xa5, 0x72, 0x72, 0x93, 0xe8, 0x81, 0xa3, 0x75, 0x87, 0x79}}

But it looks like both client and server are at least able to discover each other.

4

I solved the issue. The problem did not have anything to do with the firewall. On the server, I had changed the “default” folder entry to a different name. After I set the entry back to its default state in config.xml, waited for the client to introduce a new folder to the server, I accepted the new folder on the server and everything works now.

5