Traceroute
csvoss.scripts.mit.eduA bit unrelated... but I find it interesting that the same person who programmed this (csvoss on github) is also the developer of two other projects trending on HN right now.
Python oneliner: https://news.ycombinator.com/item?id=10114969
Retroactive data structures: https://news.ycombinator.com/item?id=10119065
Coincidence? Or is this just a slow hour on HN and good time to get submissions on front page?
Tell me about it. I've been having an exciting morning...
The oneliner was submitted early this morning, and that seems to have been the catalyst for the others.
Strike while the iron is hot.
Add this one: https://news.ycombinator.com/item?id=10119055
Any reason why all CloudFlare connections bounce through TeliaSonera in Switzerland? It seems grossly inefficient to cross the Atlantic twice just to get from Massachusetts to California.
Also, MIT -> Facebook : MA, MI, Singapore, Ireland, CA?
How accurate is the data?
The data is as of March 2014, and therefore out of date -- I'm working on updating it right now. :)
As I remember from when the data was fresh, sometimes you do get crazy hops across the Atlantic like that, though.
Maxmind data is also often just wrong, updated or not. As a hosting provider with a number of IP ranges, we have to deal with submitting corrections to them, Google, ip2location, etc. all the time. Not sure why none of them seem to use very accurate methods to discern IP location.
Since you're doing a traceroute anyhow, you'd be better off analyzing the transit hops, and specifically the city codes used in the reverse DNS entries.
International hops make the traffic less illegally intercepted by domestic espionage organizations...?
Do you verify geoip data using RTT to the hop and speed of light in optical fiber?
Slick. It also points out how inaccurate GeoIP is depending on which data source was used for that IP (eg. where the ISP is registered vs. where the endpoint may physically be).
IP Lookups are incorrect
Ex : India.gov.in [from suggestions] is on 164.100.129.97 / Page traces to some IP in China (Hysterical)!
Yeah, the MaxMind data is as of March 2014 -- out of date. Sorry about that!
If you're interested in using the http://ipinfo.io API for this, so you don't have to worry about keeping your database up to date and you get additional details, let me know. I'd be happy to hook you up with a free unlimited plan specifically for this site.
Sweet, I'd be interested! Ping me with your contact information, and I can let you know once I've wired it up to use that.
It seems like your getting this info from ARIN? Do you happen to have any restrictions on this API? Thanks!
Update: I've downloaded the GeoLite data from April 2015, replacing the old March 2014 data! You should now be seeing more accurate results. :)
Still not very accurate. It thinks my DigitalOcean droplet is in Russia. (actually in London)
.ru sure?
Yes, he ".is".
Where's the direct link to obtain a copy of this updated GeoLite data (Apr 2015) pls?
Why does 1.1.1.1 land you at google headquarters?
Whois says APNIC-LABS in Australia, but apparently this subnet is "routed briefly for passive testing".
1.1.1.0/24 [0] is described as "Research prefix for APNIC Labs", but it is part of AS15169 [1] which is "Google Inc."
Also part of that AS are 1.0.0.0/24 [2] and 1.2.3.0/24 "APNIC Debogon Project" [3]. Wikipedia has some information about Bogon filtering [4] and there have been some publications about the Debogon Project [5].
The now assigned addresses used to be unassigned "bogon" addresses, which are now assigned. I'm not sure why it's part of the Google AS, though. Maybe only because they get to see a lot of traffic?
0: http://ipinfo.io/AS15169/1.1.1.0/24
2: http://ipinfo.io/AS15169/1.0.0.0/24
3: http://ipinfo.io/AS15169/1.2.3.0/24
4: https://en.wikipedia.org/wiki/Bogon_filtering
5: http://meetings.apnic.net/__data/assets/pdf_file/0019/18811/...
Not very accurate. Using owner's address apparently: AWS servers in us-east-1 are being reported as Seattle, where Amazon is headquartered.
I've always described this as a visual, rather than text-based, traceroute. The site might benefit from keyword searching if visual traceroute was included.
Prior art: http://www.monitis.com/traceroute/
DEBUG = True error page when visiting http://csvoss.mit.edu/traceroute/request
Fixed DEBUG to be False now -- thanks! I'll see if I can fix this 500, too. :)
Would it also be possible to add the times to each step? It would be interesting to compare the time vs reported distance. I suspect the times for some hops will be impossibly fast due to bad geo-ip lookups.
Results are not very accurate. For example, we are hosted in AWS us-west-1 (San Francisco), but because Amazon owns the IP it is routing to their HQ in Seattle Washington.
It does say on the site "Uses GeoLite data from MaxMind, March 2014."
So not only is the Maxmind data well over a year out of date it's [citation needed] likely to be the free dataset which is only a subset of the Maxmind purchasable data
I'm getting a 400
This should be fixed now -- thanks!
Geo lookup for some IPs will resolve to "US" which resolves to that long/lat in the middle of Kansas in case anyone was confused.
Doesn't make sense. My AWS servers in Northern Viginia are being reported as being in Seattle area. And the route goes through London.
Agreed, most of the results I'm seeing don't make any sense at all. But IP geography has always been rather non-Euclidean.
Pretty funny to see what happens with www.1and1.com (my hosting provider). Boston to Wichita to Philadelphia... via Switzerland?
Tried with my VPS in Singapore but it failed.
Edit: It can't be serious, the packets bounced from MA to MI then ended at VA.
It's fun to see how short the distance is when using tracerouting Akamai-hosted domains.
reminds me of xtraceroute back in the days: http://www.tucows.com/preview/31913/Xtraceroute
It tries to look up IPv6 addresses as domain names, unfortunately.
I can't zoom in far enough to see many of the hops :(
Very interesting and having a lot of fun..
uTorrent offers a nice viz over a 3D globe
any chance tracing to a malicious server via this can attack scripts.mit.edu?
All I can think of is stuff like DNS cache poisoning from forcing lookups, which shouldn't be a threat these days (and there are infinite other ways to force the server to do DNS lookups). The purpose of scripts.mit.edu involves students and faculty running old versions of WordPress and writing custom PHP to learn the language, so the threat model very much assumes that malicious people have compromised at least one unprivileged account at any given time. Hostname lookups are a drop in the bucket compared to that.
Cool!
Isn't this just like the visual traceroute from http://www.yougetsignal.com/tools/visual-tracert ?