It looks like we have geopip issues on relays.syncthing.net . The reported locations lack essential information, like city or location. As expected with the transition of the free to paid geo ip location service.
When using the “free”
GeoLite2-City.mmdb as mentioned in
cmd/strelaypoolsrv/main.go IP’s do not resolve anymore to cities/locations.
If I feed it a paid version
GeoIP2-City.mmdb it works fine.
sigh… this is sad… so sad… my little lonesome geotag in Berlin now shows up in Kassel… Kassel… that’s almost Bielefeld… (germans will understand. There is no “Bielefeld”)
Maybe someone has a good idea to what kind of geoip service syncthing should move in the future ?
I don’t want to sound whiny, but my strelaysrv currently has 878 clients, 2500 sockets from all over the world.
I don’t think this is normal…
Clients is a slippery term.
Syncthing does not use geoip when picking a relay, it picks latency.
If you run your relay in Berlin, and my device A is in Berlin, it’s likely I’ll pick your relay. Regardless the fact that my device B is in Japan, if I want to talk to A from B, and there is no direct connection, I will end up connecting to your relay to talk to A from Japan.
If I take for example two IP adresses on my strelaysrv interface, both with geoiplocation in CN, both in a class C network and both using almost the same bandwidth. The only difference is: One is incoming traffic and the other is outgoing traffic.
I’ll check what geoip2-golang is used for today but it definitly is used:
And the fact is, that geoip location service @ maxmind has changed their databases a couple of days before today.
This correlates with the unnormal high socket load on our strelaysrv, which is runninng now for a couple of weeks.
Uncover the geoip conspiracy!
Sure, but someone can hardcode your relay and we can’t prevent that.
As I said, geoip is not used in the decision.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.