Python code:

results = {}
for ip0 in range(256):
  ip0_str = to_str( ip0 ) + '.'
  for ip1 in range(256):
    ip1_str = ip0_str + to_str( ip1 ) + '.'
    for ip2 in range(256):
      ip2_str = ip1_str + to_str( ip2 ) + '.'
      for ip3 in range(256):
        ip_vector = [ ip0, ip1, ip2, ip3 ]
        ip_str = ip2_str + to_str( ip3 )
        results[ ip_vector ] = ping( ip_str )

Might look a bit nicer using format strings instead. That map will contain on the order of 4 billion entries (one for each value of 2³²), and the actual size will depend on what format the ping function returns, 4 bytes for each key (optimized from my initial version that used the IPs as keys), plus all the internal structures for the map like key hashes and the hash table itself. Ie, this takes more memory to run than viewing OP’s full sized image and I wouldn’t suggest running it with less than 32GB of RAM. Though it would take less memory if it generated the image directly or at least making the keys implicit (which the image does, as they are encoded into the x, y coordinates rather than stored).

Edit: Let’s look at runtime, too, because why not. Assuming every single IP responds in 0.01 seconds (they’ll take longer, especially the ones that time out instead of respond), rounding the total to that nice 4 billion number get us 40 million seconds. An hour is less than 4000 seconds, so it would take over 100 hours to run this script.

Though it could be parallelized, since you can ping many targets at once. Not sure what the maximum number of pings you could have in flight is, but whatever it is, you’d be much better off using a script that did like 80% of that (to leave some margin for the rest of the system to use, also ISPs might not be happy with you maxing out your ICMP traffic).

Essentially, IPv4 addresses[2] are just numbers from 1 to 2147483647, for example 3405804031. However, since address routing is often based on common binary prefix, more intuitive methods like 203.0.113.255 are used. This notation is just a length-4 list of integers from 0 to 255. To convert from an integer to a common IP address, you divide-with-remainder with a constant divisor of 256. For example, 3405804031 /% 256 = (13303921,256), 13303921 /% 256 = (51968,113), 51968 /% 256 = (203,0), and 203 /% 256 = (0,203).[1] Collecting all the remainders in reverse order, then joining them with periods, produces 203.0.113.255. (This notation is just for people to read; aside from parsing code, none of IPv4 uses this notation.) When you enter an IPv4 address, the opposite happens — an expression like ((203 * 256 + 0) * 256 + 113) * 256 + 255, which evaluates to 3405804031, is performed. These octets are just numbers — using 203.000.113.255 or 203.00.113.255 in place of 203.0.113.255 is merely a choice of how to write the address, as 203 * 256 + 0 = 203 * 256 + 000. mraow

[1]: this operation can be omitted; I include it for symmetry. [2]: though all of this holds true for IPv6, I really didn’t feel like going through 128 bits of address

The “.” are just separators. Each segment is a number from 0-255 (1 byte). So you hold three segments static (e.g. 10.10.10.x) and then increment the last segment from 0-255 (so 10.10.10.0 -> 10.10.10.255). Then the next segment increments (10.10.11.0 -> 10.10.11.255).

Writing it out like 000 is just a convention. .1 is the same as .001. They are actually hex numbers from 0 to FF.