Live data from Hacker News

Show HN: Traceroute Visualizer

kriztalz.sh

11–20 of 47 posts

Re: Show HN: Traceroute Visualizer

#11
post #6

didn't work for me at all. auto-detected my IPv4 addy, but my tracert to google.com went over IPv6. I'm pretty skeptical about being able to geolocate router interfaces from IP addresses, so I was curious about the output. My expectations were low but they were too high. Oh well.

In principle, if you ping from multiple known interfaces and paths, you can infer probable location, with confidence going up with the more known points of reference you have. You can do a little calculation and triangulation based off of latency and responsive known targets traversing the same path as the endpoint you're trying to geolocate, and get a very high confidence result for zip code, city, or maybe even 3-4 block radius, if there are a bunch of ISPs in the region. Even with only 3-4 ISPs, by sourcing from different directions along different networks you can get more resolution in the final estimated radius for geolocation.

You can even use a whole bunch of fuzzy rough estimations for endpoints in a region to get progressive increments in resolution until you're happy with a precise location. You can also use educated guesses about the type of router at each hop, then use response times and behaviors for pings coming from different directions at different times. If you can arrange to traverse a node and pump traffic over it, you can use behavior with different types of traffic to elicit the type of router, the policies in place, and so on.

It's a good idea to turn off responses to pings and minimize the amount of information available, even if it seems mostly harmless. The amount of information you can get from the public internet, just in terms of basic network utility functions and behaviors, is probably a lot more than most people ever consider.

Re: Show HN: Traceroute Visualizer

#13
post #7

The calls to the ipinfo.io API are blocked by Firefox Enhanced Tracking Protection. No results for Location or ISP without turning that off.

I work for IPinfo. I did not know that our site was blocked by Firefox Enhanced Tracking Protection. Not sure what I can do here. The project takes the IP addresses you have provided from your traceroute and gets the information related to them from our website using a frontend HTTP call.

Re: Show HN: Traceroute Visualizer

#14
post #7

The calls to the ipinfo.io API are blocked by Firefox Enhanced Tracking Protection. No results for Location or ISP without turning that off.

The site is flagged as "phishing" by Palo Alto - submitted change request. edit: They updated from phishing to "computer and internet info" , no longer blocked.

Thank you very much! I work for IPinfo. I am not super familiar with the platform, so it went under my radar. I appreciate the correction.

Re: Show HN: Traceroute Visualizer

#15

I'm on my phone, maybe your site would benefit having sample data available to showcase what it can do?

I believe they already provided "Standard traceroute example", "Flyingroutes example (with protocol breakdown)" and "MTR example (with packet loss and timing statistics)".

Re: Show HN: Traceroute Visualizer

#16
post #7

The calls to the ipinfo.io API are blocked by Firefox Enhanced Tracking Protection. No results for Location or ISP without turning that off.

The site is flagged as "phishing" by Palo Alto - submitted change request. edit: They updated from phishing to "computer and internet info" , no longer blocked.

[deleted]

Re: Show HN: Traceroute Visualizer

#17
post #9

I love more tooling and attention given to latency . Throughput gets the attention but latency is what drives a high quality experience

I would not expect the latency for handling ttl expired packets to be very strongly correlated with the latency for forwarded traffic, unless exceptional conditions.

Re: Show HN: Traceroute Visualizer

#18
post #6

didn't work for me at all. auto-detected my IPv4 addy, but my tracert to google.com went over IPv6. I'm pretty skeptical about being able to geolocate router interfaces from IP addresses, so I was curious about the output. My expectations were low but they were too high. Oh well.

In principle, if you ping from multiple known interfaces and paths, you can infer probable location, with confidence going up with the more known points of reference you have. You can do a little calculation and triangulation based off of latency and responsive known targets traversing the same path as the endpoint you're trying to geolocate, and get a very high confidence result for zip code, city, or maybe even 3-4…

Traceroute isn’t “ping,” it’s exploiting TTL manipulation to generate ICMP unreachables.

You could do the long list of things you listed. Has anyone done a high-quality implementation of those things? And checked the results? I’d be interested in seeing that.

Re: Show HN: Traceroute Visualizer

#19
post #6

didn't work for me at all. auto-detected my IPv4 addy, but my tracert to google.com went over IPv6. I'm pretty skeptical about being able to geolocate router interfaces from IP addresses, so I was curious about the output. My expectations were low but they were too high. Oh well.

In principle, if you ping from multiple known interfaces and paths, you can infer probable location, with confidence going up with the more known points of reference you have. You can do a little calculation and triangulation based off of latency and responsive known targets traversing the same path as the endpoint you're trying to geolocate, and get a very high confidence result for zip code, city, or maybe even 3-4…

That only really works if ISP routing is drastically different than it usually is. When I was on DSL at my current house, the IP range available covers basically the whole multi-county metro area; all paths go through the PPPoE concentrator in a single location. You could maybe make a distance estimate from the concentrator, but there's no way to get more information than that.

I think the cable company is a bit more refined, I see cities in traceroutes that don't make sense for the whole metro area to route through, so it's likely that you can determine county, and possibly more specific. But you won't get any useful information from trying to ping outside resources; ISP networks all interconnect at the local internet exchange (or there about), when I had access to a DSL, a cable, and a local fiber ISP all in the same city, pings all went back to the IX. Maybe if you have a lot of presence in an ISP, you can gather a bit more data about users in that ISP, but it won't help you gather data about users on other ISPs.

Disabling pings is nice and all, but if you exchange any traffic, round trip times are pretty easy to gather from that. Delayed ack ads a bit of a challenge, but not much.

Of course, many isps offer geofeeds for their IPs. That's pretty reasonable to use if offered.

Re: Show HN: Traceroute Visualizer

#20

I'm on my phone, maybe your site would benefit having sample data available to showcase what it can do?

I believe they already provided "Standard traceroute example", "Flyingroutes example (with protocol breakdown)" and "MTR example (with packet loss and timing statistics)".

But you have to copy those examples from another spot in the post and paste it into the box that is already populated with placeholder information.

And for whatever reason, copy and paste on the page is flakey and required several retries on my iPhone running iOS 26.

Post reply on HN