nitefood
commented
5 months ago Hey @Strykar,
so there's a bit to unpack here, let me try to explain what happened.
First of all: IpQualityScore API key has nothing to do with bulk geolocation performed in the asn script. The "better" results from your second run are not a result of adding that API key, but rather of exactly how RIPE IPMap works.
When you first ran your asn -g commands, RIPE IPMap (the primary geolocation service the script uses when doing bulk lookups) had a location of Ranong, Ranong, TH (Thailand) associated with the IPs you were looking up. This is because IPMap had the following geofeed associated with most of these IPs:
➜ curl -s "https://ipmap.ripe.net/api/v1/locate/143.244.33.78/best" | jq '.location.geofeed'
"143.244.33.78,TH,TH-85,Ranong,"So your first asn run reported this (allegedly wrong) geolocation information in its results.
Now what IPMap does, is when you query its API and the geolocation it finds is old/stale, it triggers a new measurement using a batch of RIPE Atlas probes for your target. The probes start the measurement (basically ping the target and report back the RTT and reachability), and when it finishes, IPMap updates its geolocation information for the target(s) with fresh data ingested by its latency engine.
You can double check this is exactly what happened, because RIPE Atlas measurements and their results are public.
Let's take your targets in the 143.244.33.0/24 range: your first lookup triggered measurements 68197612, 68197610, 68197616 and 68197617 (1 IP -> 1 measurement).
If you open those measurements, and select the Latest Results tab, you will notice they could all reach the target, except in the case of IP 143.244.33.78: infact measurement 68197610 reports destination unreachable from all the probes.
This in turn triggered the IPMap update that you saw later on: All IPs are now correctly geolocated in Singapore (based on the low latency from the Atlas probes based in SG to the targets) instead of Ranong - all of which happened because your lookups triggered the measurements that made this update possible.
This alone is the reason why, in your next run (after adding the IpQualityScore token) the data is now more accurate (and explains why only 143.244.33.78 is still geolocated in Ranong).
Regarding the UK IP addresses: same sequence of events happened, you can look up the measurements you triggered by yourself here (just search by IP).
You kept seeing wrong geolocation results because the measurements weren't finished yet (except for 89.187.88.237). If you try it again now, I bet you'll get consistent UK results on all targets.
There's only one question I cannot answer for sure: why were those IPs geolocated in Thailand in the first place? I have verified using the excellent geofeed-finder that the geofeed IPMap refers to does not exist, so it's either a bug or maybe a stale leftover from the past. I don't know. The only person who may have a clue is @massimocandela (the original IPMap author).
Hope that clarifies things a bit. Thanks for the feeback!
Bulk geolocation feature may need some more testing.
It defaults every IP to
: Ranong, Ranong, TH (Thailand)here:Adding an IPQuality API improves it a bit, but it still mention Ranong:
Similar issue trying with a known list from the UK: