[tor-relays] Outdated GeoIP DB

Hi,

in the past I had already written with someone about it. At that time the entries were not up to date. There was a Gitlab issue about this, but I can't find it now.

Anyway, the data is not up to date again.

Example: https://apps.db.ripe.net/db-web-ui/query?searchtext=89.58.17.76 vs Relay Search

The IP address is currently located in Austria. But in the metrics Germany is displayed. This is a "correct" but outdated information.

Since I don't know if this can have any effects on the routing, which I don't assume, but is theoretically possible, I just want to target it again.

···

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 Like

Martin Gebhardt (Die LINKE.):

Hi,

in the past I had already written with someone about it. At that time the entries were not up to date. There was a Gitlab issue about this, but I can't find it now.

Anyway, the data is not up to date again.

Example: Webupdates ‚ÄĒ RIPE Network Coordination Centre vs Relay Search

The IP address is currently located in Austria. But in the metrics Germany is displayed. This is a "correct" but outdated information.

Since I don't know if this can have any effects on the routing, which I don't assume, but is theoretically possible, I just want to target it again.

Yes, we realized that the GeoIP db needs an update again[1]. However there is currently no newer version available[2] it seems. :frowning:

Georg

[1] AS Name is wrong for IncogNet relays (#40014) · Issues · The Tor Project / Network Health / Metrics / Relay Search · GitLab
[2] Index of /releases/libloc

2 Likes

The issue is not the version of libloc. The problem resides in an
outdated local database. The library and binaries are not the same
project/build as the database project[1], which gets updated daily.
The database is not being updated for Tor.

If you check the current lookup for the mentioned IP[2], it results in:
- Network: 89.58.16.0/22
- Announced by: AS197540 - netcup GmbH
- Country: Austria
This seems to be correct, like Martin said it should be.

[1] git.ipfire.org Git - location/location-database.git/summary
[2] location.ipfire.org - Location of 89.58.17.76

···

On Fri, Jan 21, 2022 at 1:05 PM Georg Koppen <gk@torproject.org> wrote:

Yes, we realized that the GeoIP db needs an update again[1]. However
there is currently no newer version available[2] it seems. :frowning:

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 Like

Yes, that is correct.

What surprises me, it was correct a few days.

···

On 1/21/22 12:15, Valters Jansons wrote:
> On Fri, Jan 21, 2022 at 1:05 PM Georg Koppen <gk@torproject.org> wrote:
>
> If you check the current lookup for the mentioned IP[2], it results in:
> - Network: 89.58.16.0/22
> - Announced by: AS197540 - netcup GmbH
> - Country: Austria
> This seems to be correct, like Martin said it should be.

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 Like

Yes, we realized that the GeoIP db needs an update again[1]. However
there is currently no newer version available[2] it seems. :frowning:

The issue is not the version of libloc. The problem resides in an
outdated local database. The library and binaries are not the same
project/build as the database project[1], which gets updated daily.
The database is not being updated for Tor.

If you check the current lookup for the mentioned IP[2], it results in:
- Network: 89.58.16.0/22
- Announced by: AS197540 - netcup GmbH
- Country: Austria
This seems to be correct, like Martin said it should be.

[1] git.ipfire.org Git - location/location-database.git/summary
[2] location.ipfire.org - Location of 89.58.17.76

Hey Valters,

We run the update command daily and sync the data from it.

See: location(8)

As far as I understand this should update the local DB.

Are we overlooking something?

Cheers,

-hiro

···

On 21/1/22 12:15, Valters Jansons wrote:

On Fri, Jan 21, 2022 at 1:05 PM Georg Koppen <gk@torproject.org> wrote:

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 Like

We run the update command daily and sync the data from it.

See: location(8)

As far as I understand this should update the local DB.

Are we overlooking something?

location version
Mon, 24 Jan 2022 06:02:28 GMT

location lookup 89.58.17.76
89.58.17.76:
   Network : 89.58.16.0/22
   Country : Germany
   Autonomous System : AS197540 - netcup GmbH

According to the ipfire devs the webservice at
https://location.ipfire.org/lookup/89.58.17.76
does not update the db daily, since it uses the db version when the service started.

So if you are using a daily updated version everything should fine on your side.

The remaining questions (why does it believe it is DE vs AT) is a question for the ipfire devs.

@Martin:
I can recommend their mailing list:
https://lists.ipfire.org/mailman/listinfo/location

kind regards,
nusenu

···

--
https://nusenu.github.io
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 Like

The problem has now been solved.

https://lists.ipfire.org/pipermail/location/2022-February/000523.html

···

On 1/24/22 18:31, nusenu wrote:

We run the update command daily and sync the data from it.

See: location(8)

As far as I understand this should update the local DB.

Are we overlooking something?

location version
Mon, 24 Jan 2022 06:02:28 GMT

location lookup 89.58.17.76
89.58.17.76:
Network : 89.58.16.0/22
Country : Germany
Autonomous System : AS197540 - netcup GmbH

According to the ipfire devs the webservice at
location.ipfire.org - Location of 89.58.17.76
does not update the db daily, since it uses the db version when the service started.

So if you are using a daily updated version everything should fine on your side.

The remaining questions (why does it believe it is DE vs AT) is a question for the ipfire devs.

@Martin:
I can recommend their mailing list:
https://lists.ipfire.org/mailman/listinfo/location

kind regards,
nusenu