If you like this topic, read "The Cuckoo's Egg" (1989) by Clifford Stoll
We have ipinfo at home or how to geolocate IPs in your CLI using latency
41–50 of 65 posts
Re: We have ipinfo at home or how to geolocate IPs in your CLI using latency
#42You can extend this by looking at the IP route for the reverse path, I've found it's usually accurate to the state at least on the last hop before destination - added benefit that there's usually an airport or city code on the fqdn of that hop.
Re: We have ipinfo at home or how to geolocate IPs in your CLI using latency
#43It'd be clever to integrate this into the TCP stack so it tells you immediately what the lowest bound is on the distance to the counterparty based on the time between data sent and the corresponding acknowledgements. I can see some immediate applications for that.
You can get tcp measured round trip time from tcp_info with
struct tcp_info info;
socklen_t len = sizeof(info);
getsockopt(sock, IPPROTO_TCP, TCP_INFO, &info, &len);
Re: We have ipinfo at home or how to geolocate IPs in your CLI using latency
#44This is a little project exploring the feasibility of using a service such as Globalping for geo location needs. I had fun making it but please note that the current implementation is just a demo and far from a proper production tool. If you really want to use it then for best possible results you need at least 500 probes per phase. It could be optimized fairly easily but not without going over the anon user limit wh…
isn't 3 theoretically enough?
Time of flight from three points gets you two options for position with GPS, but GPS signals propagate directly in free space. At least mostly, reflections happen.
Internet signals generally travel by cable, and the selected route may or may not be the shortest distance.
It's quite possible for traffic between neighboring countries to transit through another continent, sometimes two. And asymetric routing is also common.
Since this is using traceroute anyway, if you characterize the source nodes, you could probably use a lot fewer nodes and get similar results with something like:
a) probe from a few nodes on different continents (aiming to catch anycast nodes)
b) assuming the end of the trace is similar from all probes, choose probe nodes that are on similar networks, and some other nodes that are geolocated nearby those nodes.
c) declare the target is closest to the node with the lowest measured latency (after offsetting from node charachterized first hop latency)
You'll usually get the lowest ping times if you can ping from nearby customer of the same ISP as the target. Narrowing to that faster is possible if you know about your nodes.
Re: We have ipinfo at home or how to geolocate IPs in your CLI using latency
#45Congrats on doing it without AI! Just reading your crappy one-word commit messages make me happy.
Some code may be AI generated, because the code uses "══════" to separate terminal output. In my experience, Claude really likes to use this character to separate terminal output.
Re: We have ipinfo at home or how to geolocate IPs in your CLI using latency
#46Earlier quoted context omitted.
Packets don't travel in straight lines.
This is/was also my take. I’m skeptical that a probe-based network can be granular enough to reliably pinpoint a city, especially when some paths are much better connected than others (fewer hops, uncongested fiber, no throttling). However, ipinfo still appears to rely on active probing to triangulate geolocation data, which suggests they believe these routing asymmetries can be modeled or averaged out in practice. h…
It depends on the city, and how the ISPs in the city work.
The telco DSL and fiber in my metro area all runs through a single location where the PPPoE (hiss) concentrator is and the first hop latency from DSL interleaving swamps the latency from distance. You can someone is in the metro area, but not the county or city.
Cable company customers are a little more locatable, probably get the county.
Re: We have ipinfo at home or how to geolocate IPs in your CLI using latency
#47Congrats on doing it without AI! Just reading your crappy one-word commit messages make me happy.
Some code may be AI generated, because the code uses "══════" to separate terminal output. In my experience, Claude really likes to use this character to separate terminal output.
>Claude really likes
Plenty of developers really like it too though, because that's where Claude learned to use it.
Re: We have ipinfo at home or how to geolocate IPs in your CLI using latency
#48Congrats on doing it without AI! Just reading your crappy one-word commit messages make me happy.
Some code may be AI generated, because the code uses "══════" to separate terminal output. In my experience, Claude really likes to use this character to separate terminal output.
Maybe, but at least OP typed in the commit message by himself. That places you in the top percentile these days
Re: We have ipinfo at home or how to geolocate IPs in your CLI using latency
#49Earlier quoted context omitted.
Courtesy of Xfinity and Charter overprovisioning most neighborhood’s circuits, we already have that today for a significant subset of U.S. Internet users due to the resulting Bufferbloat (up to 2500ms on a 1000/30 connection!)
Have you seen excessive bufferbloat on a DOCSIS 3.1 modem?
Yes.
Re: We have ipinfo at home or how to geolocate IPs in your CLI using latency
#50Earlier quoted context omitted.
Courtesy of Xfinity and Charter overprovisioning most neighborhood’s circuits, we already have that today for a significant subset of U.S. Internet users due to the resulting Bufferbloat (up to 2500ms on a 1000/30 connection!)
You probably meant to say oversubscribing, not overprovisioning. Oversubscription is expected to a certain degree (this is fundamentally the same concept as "statistical multiplexing"). But even oversubscription in itself is not guaranteed to result in bufferbloat -- appropriate traffic shaping (especially to "encourage" congestion control algorithms to back off sooner) can mitigate a lot of those issues. And, it can…
Ok.