I’ve been running a relay for this for quite a while, probably years, on OpenBSD. Two days ago it stopped working and I’ve been down a bit or a rabbit hole debugging.
I think there are two things.
Firstly -protocol tcp (which is default) doesn’t bind to an IPv6 address and neither does “-protocol tcp6” - is this a bug with the OpenBSD AMD64 build?
Secondly -protocol tcp4 doesn’t prevent the relay from trying to join using it’s IPv6 endpoint, so you get something like:
2025/04/09 13:50:28 pool.go:87: Failed to join https://relays.syncthing.net/endpoint: request or check error
2025/04/09 13:50:28 pool.go:88: Response data: getting invitation: dial tcp [2001:8b0:f10:IPREMOVED::::338e]:22067: connect: connection refused (It’s refused because it never opens an IPv6 listen port)
If you specify your external IP with -ext-address xxx.xxx.xxx.xxx:22067 you get:
2025/04/09 14:38:11 pool.go:22: Joining https://relays.syncthing.net/endpoint
2025/04/09 14:38:11 pool.go:98: Failed to join https://relays.syncthing.net/endpoint: IP address not matching external address
I think what’s happened is that:
https://relays.syncthing.net/endpoint now resolves both as IPv4 and IPv6
I manually downloaded the latest build v1.29.4 and that doesn’t bind to IPv6 either and still tries to register it’s IPv6 IP when you specify -protocol tcp4
I assume “-protocol tcp4” only influences the listenning part and registering the endpoint does a gethostbyname and if IPv6 is working uses that to connect to the relay registry?
My work around for today was to build a fresh VM and not enable IPv6 on it and that’s restored the relay.