New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I did report them a few weeks ago (if I recall, it did not let me fix the location manually) and then shut them down. I can bring them back up if that would be better. They are 94.156.152.8 and 151.242.30.113, both in Bucharest, Romania.
Please bring them up. If they go down we can't test them to fix them
Got it. I've brought both back up.
Saw you on hackernews trending. Didn't know that you were on lowendtalk as well!
The world is short lol but in all honesty nice to see you in here as well. Your project's awesome!
I have done research with similar techniques to the above. Very cool and elegant project, plenty of academics I know might be able to use this to their advantage when researching IP Geolocation techniques.
I finally decided to release a web version of the tool for everyone to use. Mainly because I wanted to improve the accuracy without being limited by the number of credits I can use. This way anyone can use it
Some info:
Remember that its not a golden bullet, it basically tries to guess using latency and other hints. So don't expect 100% accuracy.
https://geolocate.globalping.dev/
Especially bad in Africa, we really need more African probes
I get "parameter validation failed" when I tried against 176.65.134.8. Another IP on that subnet worked fine though.
@jimaek A little more feedback:
You should probably exclude probes that are on the same announced prefix as the destination, otherwise you're essentially falling back to the geofeed as the source of truth. Imagine the following scenario:
This might also be why anycast detection fails sometimes. For example, it reports 160.250.225.3 (from one of my servers) as anycast, but it is in fact unicast and is in India. I suspect that's because a few incorrectly-labeled probes are out there which report back conflicting information. There could be some probe in Vietnam that is incorrectly-labeled as being in the US which would show impossibly low latency to India.
It wasn't incorrect probes but traceroutes that died too early resulting in incorrect data. They are the main source of data since ping is mostly blocked.
I made some improvements. I'm now getting India on 160.250.225.3
Unfortunately I may have to shut down most of my probes. Someone appears to be intentionally inputting honeypots and common exploit recon paths to cause everyone hosting a probe to get blacklisted. After another round of suspensions, I'm going to have to take a break until a mitigation is put in place.
@jimaek : is the time out setting static in globalping.io? Have not found any option to increase the time out in e.g. mtr tests...
We're working on it. I'll let you know when its handled.
Yes the max value is static but we plan to soon add a setting to lower it if needed
ugh, so abuse is still an issue I see.
I had someone flooding my probe with DNS requests.
Sad that people started abusing it.
i run around 20 probes and didnt receive any complaint yet... fingers crossed
There should not be any complains from any provider. We already took plenty of precautions.
The linked issue is strange and I am looking to get more information about it.
We're also gathering info internally to better understand the context and solve it properly.
@jimaek For some reason, trying to do a test with "Turkey" as the location just returns "No matching IPv4 probes available."
But doing "Istanbul" works. I just noticed that "TR" also works.
Try Türkiye. On the https://globalping.io/ UI it auto-corrects Turkey to that.
How can I trace my ips at pyongyang?
Fun fact: DPRK actually does have an intranet, but all sites are on 10.0.0.0/8 and there's no DNS so you just have to remember the IP.
Fixed https://github.com/jsdelivr/globalping/pull/912#event-30864654614
Can't think of any reason I'd ever need this but this is cool
Never had an IP with broken geolocation and wondered where it really was?
@forest I tried these https://ipinfo.io/countries/kp
Could you share a little more information?
Some people were pointing the probes at paths that trigger automated reporting on the target's end. It's being addressed with a blacklist: https://github.com/jsdelivr/globalping/pull/914
I added a handful of probes to globalping myself just today.
Thought about doing it in the past but 150/tests/day just isnt that many (esp compared to RIPE ATLAS).
But it might be useful as a backup provider should ATLAS have an issue.
Yucky. Thanks.