[bronson]

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]

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

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]

> $ 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_...

[contingencies]

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

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 :)