4 ms·

What service are you using to get that information?

bronson 12y ago
One way: ~$ ping -c1 piratebox.cc PING piratebox.cc (64.111.103.127): 56 data bytes 64 bytes from 64.111.103.127: icmp_seq=0 ttl=49 time=96.722 ms --- piratebox.cc ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 96.722/96.722/96.722/0.000 ms ~$ nslookup 64.111.103.127 Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: 127.103.111.64.in-addr.arpa name = ps43705.dreamhost.com. Authoritative answers can be found from: 103.111.64.in-addr.arpa nameserver = ns3.dreamhost.com. 103.111.64.in-addr.arpa nameserver = ns1.dreamhost.com. 103.111.64.in-addr.arpa nameserver = ns2.dreamhost.com. ns1.dreamhost.com internet address = 66.33.206.206 ns2.dreamhost.com internet address = 208.97.182.10 ns3.dreamhost.com internet address = 66.33.216.216
- contingencies 12y ago
  Heh, pre-webschool :) While we're teaching. $ whois 64.111.103.1 # Note: IP!=same, similar is ok NetRange: 64.111.96.0 - 64.111.127.255 CIDR: 64.111.96.0/19 OriginAS: AS26347 NetName: DREAMHOST-BLK4 NetHandle: NET-64-111-96-0-1 Parent: NET-64-0-0-0-0 NetType: Direct Allocation RegDate: 2005-03-07 Updated: 2013-01-18 Ref: http://whois.arin.net/rest/net/NET-64-111-96-0-1 http://whois.arin.net/rest/net/NET-64-111-96-0-1 The above shows us that the IP address range has been owned by Dreamhost since 2005. $ traceroute -M16 64.111.103.1 # Note: Hides first 15 hops traceroute to 64.111.103.1 (64.111.103.1), 64 hops max, 52 byte packets 16 te0-0-2-0.nr11.b037327-0.iad02.atlas.cogentco.com (154.24.15.62) 150.006 ms 112.416 ms 111.521 ms 17 38.122.62.254 (38.122.62.254) 110.817 ms 111.131 ms 113.563 ms 18 ip-208-113-156-8.dreamhost.com (208.113.156.8) 122.604 ms 119.393 ms 120.720 ms 19 ip-208-113-156-14.dreamhost.com (208.113.156.14) 118.675 ms 116.344 ms 116.236 ms 20 ps43497.dreamhost.com (64.111.103.1) 165.690 ms 111.885 ms 119.339 ms This shows you the carrier in use leading to the facility (cogentco). Often facilities without reverse DNS (apparently in the final hop) or without own IP ranges (as we discovered above Dreamhost has) can still be determined without actually passing traffic by reading the reverse DNS information on the closest border hop on their carrier. In this case we don't get lucky with that technique, since #17 is not showing any reverse DNS. Beyond the above you can start looking at AS-driven routing records, physical network layouts, internet historical information, etc. before resorting to more active probes.
  - pyre 12y ago
    > $ traceroute -M16 64.111.103.1 # Note: Hides first 15 hops HARD MODE: Is is actually 'hiding' those hops, or does it not even look for them? Using Apple's `traceroute.c`[1]: case 'M': /* FreeBSD compat. */ first_ttl = str2val(optarg, "first ttl", 1, 255); break; Looks like it's just bumping up the value of the first TTL. Note: For those not in the know, traceroute works by adjusting the TTL (time-to-live) value on the packet it sends out. The TTL is basically the max number of hops that the packet can take. Each 'hop' decrements the TTL value, until it reaches the destination or TTL == 0. If the TTL == 0 before it gets to the destination, then the packet it sent back as rejected. [1] http://www.opensource.apple.com/source/network_cmds/network_cmds-307.0.1/traceroute.tproj/traceroute.c http://www.opensource.apple.com/source/network_cmds/network_...
    - contingencies 12y ago
      Heh! You wouldn't need to check the code to validate the execution flow unless you're on a first-world network and so used to them that latency becomes unnoticed! In terms of comprehension for the record I would recommend instead of the source the explanation at Wikipedia: https://en.wikipedia.org/wiki/Traceroute https://en.wikipedia.org/wiki/Traceroute For awhile it used to be that people would write their own traceroute implementation as a rite of passage. As a joke, back in the 1990s, Julian Assange took it one step further and used to spoof responses to traceroutes in order send a fake route back to the querying node, indicating that his systems were somehow affiliated with important government or military entities. Excellent sense of humor :)

One way: ~$ ping -c1 piratebox.cc PING piratebox.cc (64.111.103.127): 56 data bytes 64 bytes from 64.111.103.127: icmp_seq=0 ttl=49 time=96.722 ms --- piratebox.cc ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 96.722/96.722/96.722/0.000 ms ~$ nslookup 64.111.103.127 Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: 127.103.111.64.in-addr.arpa name = ps43705.dreamhost.com. Authoritative answers can be found from: 103.111.64.in-addr.arpa nameserver = ns3.dreamhost.com. 103.111.64.in-addr.arpa nameserver = ns1.dreamhost.com. 103.111.64.in-addr.arpa nameserver = ns2.dreamhost.com. ns1.dreamhost.com internet address = 66.33.206.206 ns2.dreamhost.com internet address = 208.97.182.10 ns3.dreamhost.com internet address = 66.33.216.216

contingencies 12y ago
Heh, pre-webschool :) While we're teaching. $ whois 64.111.103.1 # Note: IP!=same, similar is ok NetRange: 64.111.96.0 - 64.111.127.255 CIDR: 64.111.96.0/19 OriginAS: AS26347 NetName: DREAMHOST-BLK4 NetHandle: NET-64-111-96-0-1 Parent: NET-64-0-0-0-0 NetType: Direct Allocation RegDate: 2005-03-07 Updated: 2013-01-18 Ref: http://whois.arin.net/rest/net/NET-64-111-96-0-1 http://whois.arin.net/rest/net/NET-64-111-96-0-1 The above shows us that the IP address range has been owned by Dreamhost since 2005. $ traceroute -M16 64.111.103.1 # Note: Hides first 15 hops traceroute to 64.111.103.1 (64.111.103.1), 64 hops max, 52 byte packets 16 te0-0-2-0.nr11.b037327-0.iad02.atlas.cogentco.com (154.24.15.62) 150.006 ms 112.416 ms 111.521 ms 17 38.122.62.254 (38.122.62.254) 110.817 ms 111.131 ms 113.563 ms 18 ip-208-113-156-8.dreamhost.com (208.113.156.8) 122.604 ms 119.393 ms 120.720 ms 19 ip-208-113-156-14.dreamhost.com (208.113.156.14) 118.675 ms 116.344 ms 116.236 ms 20 ps43497.dreamhost.com (64.111.103.1) 165.690 ms 111.885 ms 119.339 ms This shows you the carrier in use leading to the facility (cogentco). Often facilities without reverse DNS (apparently in the final hop) or without own IP ranges (as we discovered above Dreamhost has) can still be determined without actually passing traffic by reading the reverse DNS information on the closest border hop on their carrier. In this case we don't get lucky with that technique, since #17 is not showing any reverse DNS. Beyond the above you can start looking at AS-driven routing records, physical network layouts, internet historical information, etc. before resorting to more active probes.
- pyre 12y ago
  > $ traceroute -M16 64.111.103.1 # Note: Hides first 15 hops HARD MODE: Is is actually 'hiding' those hops, or does it not even look for them? Using Apple's `traceroute.c`[1]: case 'M': /* FreeBSD compat. */ first_ttl = str2val(optarg, "first ttl", 1, 255); break; Looks like it's just bumping up the value of the first TTL. Note: For those not in the know, traceroute works by adjusting the TTL (time-to-live) value on the packet it sends out. The TTL is basically the max number of hops that the packet can take. Each 'hop' decrements the TTL value, until it reaches the destination or TTL == 0. If the TTL == 0 before it gets to the destination, then the packet it sent back as rejected. [1] http://www.opensource.apple.com/source/network_cmds/network_cmds-307.0.1/traceroute.tproj/traceroute.c http://www.opensource.apple.com/source/network_cmds/network_...
  - contingencies 12y ago
    Heh! You wouldn't need to check the code to validate the execution flow unless you're on a first-world network and so used to them that latency becomes unnoticed! In terms of comprehension for the record I would recommend instead of the source the explanation at Wikipedia: https://en.wikipedia.org/wiki/Traceroute https://en.wikipedia.org/wiki/Traceroute For awhile it used to be that people would write their own traceroute implementation as a rite of passage. As a joke, back in the 1990s, Julian Assange took it one step further and used to spoof responses to traceroutes in order send a fake route back to the querying node, indicating that his systems were somehow affiliated with important government or military entities. Excellent sense of humor :)