7 ms·

We have ipinfo at home or how to geolocate IPs in your CLI using latency

228 points by jimaek 8mo ago

lopoc 8mo ago
Nice work! I presented similar research at DEFCON 31 - 'You Can't Cheat Time: Finding foes and yourself with latency trilateration' https://youtu.be/_iAffzWxexA https://youtu.be/_iAffzWxexA though with some key differences that address the limitations mentioned in the thread. The main issue with pure ping-based geolocation is that: IPs are already geolocated in databases (as you note) Routing asymmetries break the distance model Anycast/CDNs make single IPs appear in multiple locations ICMP can be blocked or deprioritized My approach used HTTP(S) latency measurements (not ping) with an ML model (SVR) trained on ~39k datapoints to handle internet routing non-linearity, then performed trilateration via optimization. Accuracy was ~600km for targets behind CloudFront - not precise, but enough to narrow attribution from "anywhere" to "probably Europe" for C2 servers. The real value isn't precision but rather: Detecting sandboxes via physically impossible latency patterns Enabling geo-fenced malware Providing any location signal when traditional IP geolocation fails Talk: https://youtu.be/_iAffzWxexA https://youtu.be/_iAffzWxexA"
- tylervigen 8mo ago
  I suppose if your goal was to not be found, you could "cheat time" by implementing a random delay on all outgoing packets. The second iteration of this would be to spoof latency based on where you want to appear to be, by creating rules for intentional latency based on the source of the ping.
  - lopoc 8mo ago
    yes but you cannot appear nearer than where you actually are! it's the law! TLDR latency tell you where someone for sure is not!
- rixed 8mo ago
  FYI, speed of light in fiber is much less than 300Mm/s. a simple rule of thumb is that a signal using optical fiber for communication will travel at around 200,000 kilometers per second -- https://en.wikipedia.org/wiki/Optical_fiber https://en.wikipedia.org/wiki/Optical_fiber
tallytarik 8mo ago
Great post and a great little tool. Some of my experience using these techniques in production: 1. Trilateration mostly doesn't work with internet routing, unlike GPS. Other commenters have covered this in more detail. So the approach described here - to take the closest single measurement - is often the best you can do without prior data. This means you need a crazy high distribution of nodes across cities to get useful data at scale. We run our own servers and also sponsor Globalping and use RIPE Atlas for some measurements (I work for a geo data provider), yet even with thousands of available probes, we can only accurately infer latency-based location for IPs very close to those probes. 2. As such, latency/traceroute measurements are most useful for verifying existing location data. That means for the vast majority of IP space, we rely on having something to compare against. 3. Traceroute hops are good; the caveat being that you're geolocating a router. RIPE IPmap already locates most public routers with good precision. 4. Overall these techniques work quite well for infrastructure and server IP addresses but less so for eyeball networks. https://ping.sx https://ping.sx is also a nice comparison tool
- lopoc 8mo ago
  agree but... https://youtu.be/_iAffzWxexA https://youtu.be/_iAffzWxexA 20 minutes talk at DEFCON
nickorlow 8mo ago
Wonder if you can do this with mobile phones by timing the time to the first ring?
reincoder 8mo ago
Thank you, Dimitry. Everyone at IPinfo really appreciates the shoutout! --- Our research scientist, Calvin, will be giving a talk at NANOG96 on Monday that delves into active measurement-based IP geolocation. https://nanog.org/events/nanog-96/content/5678/ https://nanog.org/events/nanog-96/content/5678/
jimaek 8mo ago
This 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 which I tried to avoid
- kortex 8mo ago
  I wonder if you could optimize for reducing the total probe count (at the expense of possibly longer total time, though it may be faster in some cases) by using some sort of "gradient descent". Start by doing the multi-continent probe, say 3x each. Drop the longest time probes, add probes near the shortest time, and probe once. Repeat this pattern of probe, assess, drop and add closer to the target. You accumulate all data in your orchestrator, so in theory you don't need to deliberately issue multiple probes each round (except for the first) to get statistical power. I would expect this to "chase" the real location continuously instead of 5 discrete phases. I just watched the Veritasium video on potentials and vector fields - the latency is a scalar potential field of sorts, and you could use it to derive a latency gradient.
  - jimaek 8mo ago
    Yes, most likely there are multiple algorithms that could be used to get better results with fewer probes, but I'm not smart enough to do the math and implement them.
    - kortex 8mo ago
      The simplest is drop the longest latency probe, and add a new one in the proximity of the fastest.
- TZubiri 8mo ago
  isn't 3 theoretically enough?
Havoc 8mo ago
Bit surprised this works. Latency variability is huge and sometimes quite disconnected from geo location. I recall talking to someone in NL and realised I've got better latency to NL content from the UK than he did. Presumably better peering etc.
- TacticalCoder 8mo ago
  > Latency variability is huge ... Yup. For example from my city to one of my dedicated server whose location is fully well-know (in France), I know there's 250 kilometers as the crow flies. Yet if I ping that server and draw a circle around my place (considering ping travels as fast as light in a vaccuum, which we know ain't happening but, hey, it's something) I get a radius of 2000 kilometers. About 8x the distance. I can prove that my IP ain't in the US but that's still not very precise. And indeed many servers in the UK, which is 2x the distance than my server is, gives me constantly a lower ping. TFA's approach, especially with the traceroute instead of Ping, is nice.
- reincoder 8mo ago
  I work for IPinfo. We are launching a collaborative project with IXPs and major internet organizations to share raw measurement for routing and peering data for this purpose. Latency variability is a huge issue. We run both traceroute and ping data, and we observe that there are entire countries that peer with IXP thousands of miles away in a different continent. We bought a server from the oldest telecom company in the country and recently activated it. Currently, there is a 20 ms latency when traffic is directed towards the second oldest telecom. The packets have to travel outside the country before coming back in. This is a common phenomenon that occurs frequently. So, we usually have multiple servers in major cities since various ASNs have different peering policies. For us we can map those behaviors and have algorithms and other data sources, make measurement-based geolocation perform well. We are hoping to support IXPs, internet governance agencies, and major telcoms in identifying these issues and resolving them.
  - toast0 8mo ago
    What is your path towards 'resolving' these issues? I've done some mapping while comparing turn servers my org hosted on cloud vms vs a commercial offering, and it's pretty easy to find very different routing from point A to point B, but sometimes it's pretty clearly that not every transit network has access to every submarine cable, so traffic from say Brazil to South Africa might go from Brazil directly to Africa, or it might go to Florida, then Europe, then Africa. It'd be nice to take a more direct route, but maybe the Brazil -> Africa hop doesn't transit all the way, so BGP prefers the scenic route as it has a shorter AS path. I didn't have any leverage to motivate routing changes though, so other than saying hmm, that's interesting, there wasn't much to do about it.
greyface- 8mo ago
How feasible would it be for the host under measurement to introduce additional artificial latency to ping responses, varying based on source IP, in order to spoof its measured location?
- rnhmjoj 8mo ago
  Traceroutes are already notoriously hard to interpret correctly[1] and yes, they can be trivially spoofed. Remember the stunt[2] pulled by tpb to move to North Korea? If you are an AS you can also prepend fake AS to your BGP announcements and make the spoofed traceroute even more legitimate. I wonder if this thing will start a cat and mouse game with VPNs. [1]: https://old.reddit.com/r/networking/comments/1hkm4g/lets_talk_about_traceroute/cavh7ub/?context=3#cavh7ub https://old.reddit.com/r/networking/comments/1hkm4g/lets_tal... [2]: https://news.ycombinator.com/item?id=5319419 https://news.ycombinator.com/item?id=5319419
- maccard 8mo ago
  Totally feasible but a bit like all these situations - it’s not happening in practice.
  - danuel 8mo ago
    Hacks
- Retr0id 8mo ago
  Not-impossible, but it would be a whole lot simpler to just not respond to pings in the first place.
  - Retr0id 8mo ago
    But also, as mentioned in https://news.ycombinator.com/item?id=46836803 https://news.ycombinator.com/item?id=46836803 , someone can still probe the second-last hop and get pretty close.
- walletdrainer 8mo ago
  Totally feasible. You could do even cooler tricks, like https://github.com/blechschmidt/fakeroute https://github.com/blechschmidt/fakeroute Pointless? Almost certainly.
DenisDolya 8mo ago
Wow, it works !
lpapez 8mo ago
Amazing idea and execution, the sort of stuff I wish there was more of on HN.
xyst 8mo ago
Tried with an IP allocated to a major wireless network operator. It was far off but also ran out of credits when trying with higher limits on subsequent attempts. Seems tool is relying on ICMP results from various probes. So wouldn't this project become useless if target device disables ICMP? I wonder if you can "fake" results by having your gateway/device respond with fake ICMP requests.
- jimaek 8mo ago
  I talk about it a bit in the article. The easiest solution is to use the last available hop. In most cases its close enough to properly detect the country even if the target blocks ICMP. Email me if you would like to get some additional credits to test it out, dakulovgr gmail.
westurner 8mo ago
Wi-FI RTT is more accurate than trilateration with RSSI but requires hw support. IEEE 802.11mc > Wi-Fi Round Trip Time (RTT) https://en.wikipedia.org/wiki/IEEE_802.11mc#Wi-Fi_Round_Trip_Time https://en.wikipedia.org/wiki/IEEE_802.11mc#Wi-Fi_Round_Trip... /? fine time measurement FTM: https://www.google.com/search?q=fine+time+measurement+FTM https://www.google.com/search?q=fine+time+measurement+FTM
navigate8310 8mo ago
> Globalping is an open-source, community-powered project that allows users to self-host container-based probes. These probes then become part of our public network, which allows anyone to use them to run network testing tools such as ping and traceroute. How's this different from RIPE ATLAS?
- jimaek 8mo ago
  Atlas is great but it is focused more on academic research and professional use. Globalping offers real-time result streaming and a simpler user experience with focus on integrations https://globalping.io/integrations https://globalping.io/integrations For example you can use the CLI as if you were running a traceroute locally, without even having to register. And if you need more credits you can simply donate via GitHub Sponsors starting from $1 They are similar with an overlapping audience yet have different goals
navigate8310 8mo ago
> Group and sort the results; the country with the lowest latency should be the correct one Sometimes residential ISPs (that hosts the probe) may have a bad routing due to many factors, how does the algorithm take that into account?
- direwolf20 8mo ago
  You have a lot of probes so you also have one with good routing
VladVladikoff 8mo ago
If I understood the post the author just takes the location of smallest ping as the winner. This seems like a very rudimentary approach. Why not do triangulation? If you take each ping time as a measurement of distance between two points, you should be able to ping from a random selection of IPs and from there calculate the location.
- direwolf20 8mo ago
  Packets don't travel in straight lines.
  - coffeeri 8mo ago
    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. https://ipinfo.io/blog/ipinfos-probe-network https://ipinfo.io/blog/ipinfos-probe-network
    - toast0 8mo ago
      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.
    - direwolf20 8mo ago
      I think the idea is that if you have enough probes, one of them will be in the right location and network. Tier 2 ISPs have the right incentives to peer with every network in every peering point, so you are likely to get a correct result from a different ISP. Tier 1 ISPs avoid peering, so if your probe or target is on Deutsche Telekom or Cogent, your packet takes a circuitous route, passing only through networks that paid the extortion money. Friends don't let friends get internet service from Deutsche Telekom or Cogent.
maximgeorge 8mo ago
[dead]
jacquesm 8mo ago
It'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.
- toast0 8mo ago
  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); tcp_info varies by OS and version, but I think tcpi_rtt is well supported.
jurgenaut23 8mo ago
Congrats on doing it without AI! Just reading your crappy one-word commit messages make me happy.
- networkcat 8mo ago
  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.
  - Almondsetat 8mo ago
    >Claude really likes Plenty of developers really like it too though, because that's where Claude learned to use it.
  - jurgenaut23 8mo ago
    Maybe, but at least OP typed in the commit message by himself. That places you in the top percentile these days
29athrowaway 8mo ago
If you like this topic, read "The Cuckoo's Egg" (1989) by Clifford Stoll
tgtweak 8mo ago
You 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.

228 points by jimaek 8mo ago

lopoc 8mo ago

Nice work! I presented similar research at DEFCON 31 - 'You Can't Cheat Time: Finding foes and yourself with latency trilateration' https://youtu.be/_iAffzWxexA https://youtu.be/_iAffzWxexA though with some key differences that address the limitations mentioned in the thread. The main issue with pure ping-based geolocation is that: IPs are already geolocated in databases (as you note) Routing asymmetries break the distance model Anycast/CDNs make single IPs appear in multiple locations ICMP can be blocked or deprioritized My approach used HTTP(S) latency measurements (not ping) with an ML model (SVR) trained on ~39k datapoints to handle internet routing non-linearity, then performed trilateration via optimization. Accuracy was ~600km for targets behind CloudFront - not precise, but enough to narrow attribution from "anywhere" to "probably Europe" for C2 servers. The real value isn't precision but rather: Detecting sandboxes via physically impossible latency patterns Enabling geo-fenced malware Providing any location signal when traditional IP geolocation fails Talk: https://youtu.be/_iAffzWxexA https://youtu.be/_iAffzWxexA"

tylervigen 8mo ago
I suppose if your goal was to not be found, you could "cheat time" by implementing a random delay on all outgoing packets. The second iteration of this would be to spoof latency based on where you want to appear to be, by creating rules for intentional latency based on the source of the ping.
- lopoc 8mo ago
  yes but you cannot appear nearer than where you actually are! it's the law! TLDR latency tell you where someone for sure is not!
rixed 8mo ago
FYI, speed of light in fiber is much less than 300Mm/s. a simple rule of thumb is that a signal using optical fiber for communication will travel at around 200,000 kilometers per second -- https://en.wikipedia.org/wiki/Optical_fiber https://en.wikipedia.org/wiki/Optical_fiber

tallytarik 8mo ago

Great post and a great little tool. Some of my experience using these techniques in production: 1. Trilateration mostly doesn't work with internet routing, unlike GPS. Other commenters have covered this in more detail. So the approach described here - to take the closest single measurement - is often the best you can do without prior data. This means you need a crazy high distribution of nodes across cities to get useful data at scale. We run our own servers and also sponsor Globalping and use RIPE Atlas for some measurements (I work for a geo data provider), yet even with thousands of available probes, we can only accurately infer latency-based location for IPs very close to those probes. 2. As such, latency/traceroute measurements are most useful for verifying existing location data. That means for the vast majority of IP space, we rely on having something to compare against. 3. Traceroute hops are good; the caveat being that you're geolocating a router. RIPE IPmap already locates most public routers with good precision. 4. Overall these techniques work quite well for infrastructure and server IP addresses but less so for eyeball networks. https://ping.sx https://ping.sx is also a nice comparison tool

lopoc 8mo ago
agree but... https://youtu.be/_iAffzWxexA https://youtu.be/_iAffzWxexA 20 minutes talk at DEFCON

nickorlow 8mo ago

Wonder if you can do this with mobile phones by timing the time to the first ring?

reincoder 8mo ago

Thank you, Dimitry. Everyone at IPinfo really appreciates the shoutout! --- Our research scientist, Calvin, will be giving a talk at NANOG96 on Monday that delves into active measurement-based IP geolocation. https://nanog.org/events/nanog-96/content/5678/ https://nanog.org/events/nanog-96/content/5678/

jimaek 8mo ago

This 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 which I tried to avoid

kortex 8mo ago
I wonder if you could optimize for reducing the total probe count (at the expense of possibly longer total time, though it may be faster in some cases) by using some sort of "gradient descent". Start by doing the multi-continent probe, say 3x each. Drop the longest time probes, add probes near the shortest time, and probe once. Repeat this pattern of probe, assess, drop and add closer to the target. You accumulate all data in your orchestrator, so in theory you don't need to deliberately issue multiple probes each round (except for the first) to get statistical power. I would expect this to "chase" the real location continuously instead of 5 discrete phases. I just watched the Veritasium video on potentials and vector fields - the latency is a scalar potential field of sorts, and you could use it to derive a latency gradient.
- jimaek 8mo ago
  Yes, most likely there are multiple algorithms that could be used to get better results with fewer probes, but I'm not smart enough to do the math and implement them.
  - kortex 8mo ago
    The simplest is drop the longest latency probe, and add a new one in the proximity of the fastest.
TZubiri 8mo ago
isn't 3 theoretically enough?

Havoc 8mo ago

Bit surprised this works. Latency variability is huge and sometimes quite disconnected from geo location. I recall talking to someone in NL and realised I've got better latency to NL content from the UK than he did. Presumably better peering etc.

TacticalCoder 8mo ago
> Latency variability is huge ... Yup. For example from my city to one of my dedicated server whose location is fully well-know (in France), I know there's 250 kilometers as the crow flies. Yet if I ping that server and draw a circle around my place (considering ping travels as fast as light in a vaccuum, which we know ain't happening but, hey, it's something) I get a radius of 2000 kilometers. About 8x the distance. I can prove that my IP ain't in the US but that's still not very precise. And indeed many servers in the UK, which is 2x the distance than my server is, gives me constantly a lower ping. TFA's approach, especially with the traceroute instead of Ping, is nice.
reincoder 8mo ago
I work for IPinfo. We are launching a collaborative project with IXPs and major internet organizations to share raw measurement for routing and peering data for this purpose. Latency variability is a huge issue. We run both traceroute and ping data, and we observe that there are entire countries that peer with IXP thousands of miles away in a different continent. We bought a server from the oldest telecom company in the country and recently activated it. Currently, there is a 20 ms latency when traffic is directed towards the second oldest telecom. The packets have to travel outside the country before coming back in. This is a common phenomenon that occurs frequently. So, we usually have multiple servers in major cities since various ASNs have different peering policies. For us we can map those behaviors and have algorithms and other data sources, make measurement-based geolocation perform well. We are hoping to support IXPs, internet governance agencies, and major telcoms in identifying these issues and resolving them.
- toast0 8mo ago
  What is your path towards 'resolving' these issues? I've done some mapping while comparing turn servers my org hosted on cloud vms vs a commercial offering, and it's pretty easy to find very different routing from point A to point B, but sometimes it's pretty clearly that not every transit network has access to every submarine cable, so traffic from say Brazil to South Africa might go from Brazil directly to Africa, or it might go to Florida, then Europe, then Africa. It'd be nice to take a more direct route, but maybe the Brazil -> Africa hop doesn't transit all the way, so BGP prefers the scenic route as it has a shorter AS path. I didn't have any leverage to motivate routing changes though, so other than saying hmm, that's interesting, there wasn't much to do about it.

greyface- 8mo ago

How feasible would it be for the host under measurement to introduce additional artificial latency to ping responses, varying based on source IP, in order to spoof its measured location?

rnhmjoj 8mo ago
Traceroutes are already notoriously hard to interpret correctly[1] and yes, they can be trivially spoofed. Remember the stunt[2] pulled by tpb to move to North Korea? If you are an AS you can also prepend fake AS to your BGP announcements and make the spoofed traceroute even more legitimate. I wonder if this thing will start a cat and mouse game with VPNs. [1]: https://old.reddit.com/r/networking/comments/1hkm4g/lets_talk_about_traceroute/cavh7ub/?context=3#cavh7ub https://old.reddit.com/r/networking/comments/1hkm4g/lets_tal... [2]: https://news.ycombinator.com/item?id=5319419 https://news.ycombinator.com/item?id=5319419
maccard 8mo ago
Totally feasible but a bit like all these situations - it’s not happening in practice.
- danuel 8mo ago
  Hacks
Retr0id 8mo ago
Not-impossible, but it would be a whole lot simpler to just not respond to pings in the first place.
- Retr0id 8mo ago
  But also, as mentioned in https://news.ycombinator.com/item?id=46836803 https://news.ycombinator.com/item?id=46836803 , someone can still probe the second-last hop and get pretty close.
walletdrainer 8mo ago
Totally feasible. You could do even cooler tricks, like https://github.com/blechschmidt/fakeroute https://github.com/blechschmidt/fakeroute Pointless? Almost certainly.

DenisDolya 8mo ago

Wow, it works !

lpapez 8mo ago

Amazing idea and execution, the sort of stuff I wish there was more of on HN.

xyst 8mo ago

Tried with an IP allocated to a major wireless network operator. It was far off but also ran out of credits when trying with higher limits on subsequent attempts. Seems tool is relying on ICMP results from various probes. So wouldn't this project become useless if target device disables ICMP? I wonder if you can "fake" results by having your gateway/device respond with fake ICMP requests.

jimaek 8mo ago
I talk about it a bit in the article. The easiest solution is to use the last available hop. In most cases its close enough to properly detect the country even if the target blocks ICMP. Email me if you would like to get some additional credits to test it out, dakulovgr gmail.

westurner 8mo ago

Wi-FI RTT is more accurate than trilateration with RSSI but requires hw support. IEEE 802.11mc > Wi-Fi Round Trip Time (RTT) https://en.wikipedia.org/wiki/IEEE_802.11mc#Wi-Fi_Round_Trip_Time https://en.wikipedia.org/wiki/IEEE_802.11mc#Wi-Fi_Round_Trip... /? fine time measurement FTM: https://www.google.com/search?q=fine+time+measurement+FTM https://www.google.com/search?q=fine+time+measurement+FTM

navigate8310 8mo ago

> Globalping is an open-source, community-powered project that allows users to self-host container-based probes. These probes then become part of our public network, which allows anyone to use them to run network testing tools such as ping and traceroute. How's this different from RIPE ATLAS?

jimaek 8mo ago
Atlas is great but it is focused more on academic research and professional use. Globalping offers real-time result streaming and a simpler user experience with focus on integrations https://globalping.io/integrations https://globalping.io/integrations For example you can use the CLI as if you were running a traceroute locally, without even having to register. And if you need more credits you can simply donate via GitHub Sponsors starting from $1 They are similar with an overlapping audience yet have different goals

navigate8310 8mo ago

> Group and sort the results; the country with the lowest latency should be the correct one Sometimes residential ISPs (that hosts the probe) may have a bad routing due to many factors, how does the algorithm take that into account?

direwolf20 8mo ago
You have a lot of probes so you also have one with good routing

VladVladikoff 8mo ago

If I understood the post the author just takes the location of smallest ping as the winner. This seems like a very rudimentary approach. Why not do triangulation? If you take each ping time as a measurement of distance between two points, you should be able to ping from a random selection of IPs and from there calculate the location.

direwolf20 8mo ago
Packets don't travel in straight lines.
- coffeeri 8mo ago
  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. https://ipinfo.io/blog/ipinfos-probe-network https://ipinfo.io/blog/ipinfos-probe-network
  - toast0 8mo ago
    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.
  - direwolf20 8mo ago
    I think the idea is that if you have enough probes, one of them will be in the right location and network. Tier 2 ISPs have the right incentives to peer with every network in every peering point, so you are likely to get a correct result from a different ISP. Tier 1 ISPs avoid peering, so if your probe or target is on Deutsche Telekom or Cogent, your packet takes a circuitous route, passing only through networks that paid the extortion money. Friends don't let friends get internet service from Deutsche Telekom or Cogent.

maximgeorge 8mo ago

[dead]

jacquesm 8mo ago

It'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.

toast0 8mo ago
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); tcp_info varies by OS and version, but I think tcpi_rtt is well supported.

jurgenaut23 8mo ago

Congrats on doing it without AI! Just reading your crappy one-word commit messages make me happy.

networkcat 8mo ago
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.
- Almondsetat 8mo ago
  >Claude really likes Plenty of developers really like it too though, because that's where Claude learned to use it.
- jurgenaut23 8mo ago
  Maybe, but at least OP typed in the commit message by himself. That places you in the top percentile these days

29athrowaway 8mo ago

If you like this topic, read "The Cuckoo's Egg" (1989) by Clifford Stoll

tgtweak 8mo ago

You 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.