Show HN: Faster-than-light ping (April Fools')

Overflow in busybox ping!<p><pre><code> 64 bytes from 82.165.188.205: seq=0 ttl=52 time=172.825 ms 64 bytes from 82.165.188.205: seq=1 ttl=52 time=182.433 ms 64 bytes from 82.165.188.205: seq=2 ttl=52 time=221.810 ms 64 bytes from 82.165.188.205: seq=3 ttl=52 time=96.547 ms 64 bytes from 82.165.188.205: seq=4 ttl=52 time=89.722 ms 64 bytes from 82.165.188.205: seq=5 ttl=52 time=77.812 ms 64 bytes from 82.165.188.205: seq=6 ttl=52 time=68.624 ms 64 bytes from 82.165.188.205: seq=7 ttl=52 time=57.501 ms 64 bytes from 82.165.188.205: seq=8 ttl=52 time=48.275 ms 64 bytes from 82.165.188.205: seq=9 ttl=52 time=37.498 ms 64 bytes from 82.165.188.205: seq=10 ttl=52 time=22.236 ms 64 bytes from 82.165.188.205: seq=11 ttl=52 time=23.625 ms 64 bytes from 82.165.188.205: seq=12 ttl=52 time=9.215 ms 64 bytes from 82.165.188.205: seq=13 ttl=52 time=4.496 ms 64 bytes from 82.165.188.205: seq=14 ttl=52 time=5.311 ms 64 bytes from 82.165.188.205: seq=15 ttl=52 time=3.678 ms 64 bytes from 82.165.188.205: seq=16 ttl=52 time=3.261 ms 64 bytes from 82.165.188.205: seq=17 ttl=52 time=4294933.513 ms 64 bytes from 82.165.188.205: seq=18 ttl=52 time=4294938.415 ms 64 bytes from 82.165.188.205: seq=19 ttl=52 time=3.640 ms</code></pre>

This is fun. It&#x27;s literally like back in the past:<p><pre><code> 64 bytes from 82.165.188.205: icmp_seq=40 ttl=50 time=18.069 ms 64 bytes from 82.165.188.205: icmp_seq=41 ttl=50 time=-47.262 ms 64 bytes from 82.165.188.205: icmp_seq=42 ttl=50 time=-62.118 ms 64 bytes from 82.165.188.205: icmp_seq=43 ttl=50 time=-123.935 ms 64 bytes from 82.165.188.205: icmp_seq=44 ttl=50 time=-130.247 ms 64 bytes from 82.165.188.205: icmp_seq=45 ttl=50 time=-141.351 ms 64 bytes from 82.165.188.205: icmp_seq=46 ttl=50 time=-98.121 ms 64 bytes from 82.165.188.205: icmp_seq=47 ttl=50 time=-141.229 ms 64 bytes from 82.165.188.205: icmp_seq=48 ttl=50 time=-170.218 ms 64 bytes from 82.165.188.205: icmp_seq=49 ttl=50 time=-186.823 ms 64 bytes from 82.165.188.205: icmp_seq=50 ttl=50 time=-176.823 ms 64 bytes from 82.165.188.205: icmp_seq=51 ttl=50 time=-207.752 ms 64 bytes from 82.165.188.205: icmp_seq=52 ttl=50 time=-223.770 ms 64 bytes from 82.165.188.205: icmp_seq=53 ttl=50 time=-223.758 ms 64 bytes from 82.165.188.205: icmp_seq=54 ttl=50 time=-149.182 ms 64 bytes from 82.165.188.205: icmp_seq=55 ttl=50 time=-227.685 ms 64 bytes from 82.165.188.205: icmp_seq=56 ttl=50 time=-263.873 ms 64 bytes from 82.165.188.205: icmp_seq=57 ttl=50 time=-258.082 ms</code></pre>

Amazing!<p>I can imagine how it works on the server side, but what&#x27;s really fascinating is that my client (macOS) can handle negative response times at all.<p>Does anybody know how that&#x27;s possible? Do ICMP sockets just queue incoming &quot;responses&quot; until there is a pending matching request?<p>Or does the ping command take complete ICMP &quot;ownership&quot; over... something? more than a socket? while it runs, and this is an implementation quirk of that userspace tool&#x27;s synchronization&#x2F;threading&#x2F;event handling mechanisms?

Ubuntu<p><pre><code> PING ftlping.net (82.165.188.205) 56(84) bytes of data. 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=1 ttl=49 time=131 ms 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=2 ttl=49 time=121 ms 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=3 ttl=49 time=110 ms 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=4 ttl=49 time=88.0 ms 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=5 ttl=49 time=105 ms 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=6 ttl=49 time=80.5 ms 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=7 ttl=49 time=69.9 ms 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=8 ttl=49 time=58.6 ms 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=9 ttl=49 time=55.8 ms 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=10 ttl=49 time=40.1 ms 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=11 ttl=49 time=30.7 ms 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=12 ttl=49 time=20.6 ms ping: Warning: time of day goes back (-7859us), taking countermeasures ping: Warning: time of day goes back (-7746us), taking countermeasures 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=13 ttl=49 time=0.000 ms 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=14 ttl=49 time=18.7 ms ping: Warning: time of day goes back (-8431us), taking countermeasures 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=15 ttl=49 time=0.000 ms ping: Warning: time of day goes back (-17099us), taking countermeasures 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=16 ttl=49 time=0.000 ms ping: Warning: time of day goes back (-27144us), taking countermeasures 64 bytes from rfc6921.net (82.165.188.205): icmp_seq=17 ttl=49 time=0.000 ms</code></pre>

On windows after some time I am getting:<p>Request timed out.<p>And on linux:<p>ping: Warning: time of day goes back (-173217us), taking countermeasures 64 bytes from [redacted]: icmp_seq=31 ttl=55 time=0.000 ms

Some years ago some papers were published claiming reliable quantum teleportation has finally been invented. This made me wonder if we are going to get microscopic pings over huge distances anytime soon.

Very nice. Takes a special mind to think about tweaking the contents of ping packets :)<p>Now, by rights, you&#x27;ve shown that I shouldn&#x27;t trust <i>anything</i> I receive from <i>anybody</i>.

HAHA thats pretty cool even as just a concept to show how ping works and can be manipulated.

I&#x27;m getting a timeout :)

&quot;somebody&#x27;s printing up packets!&quot;