liboping
liboping copied to clipboard
oping should failover correctly to IPv4
On some IPv4-only networks, DNS results sometimes include AAAA records. Most programs correctly handle this situation and fall back to the A record. For example, if you curl www.torproject.org, it uses the A or AAAA record depending on whether you are on a IPv6 or IPv4 network.
On an IPv4-only network:
anarcat@curie:~(main)$ curl -s -v -I www.torproject.org 2>&1 | head -1
* Trying 116.202.120.165:80...
On an IPv6 (dual-stack) network:
anarcat@marcos:~$ curl -s -v -I www.torproject.org 2>&1 | head -1
* Trying 2604:8800:5000:82:466:38ff:fecb:d46e:80...
In other words, marcos is on an IPv6 network, curie isn't. curie's network does give out AAAA records however, which might be a mistake, but that's besides the point: IPv6 could be down for other reasons here, for example upstream routing issues, intermittent packet loss, etc.
This is not specific to curl, web browsers (tested in Firefox) also handle this gracefully. This is actually documented in a draft RFC (draft-grinnemo-taps-he, also known as Happy eyeballs) which has unfortunately expired but has been generally adopted widely.
oping (and, obviously noping) doesn't handle this correctly:
anarcat@curie:~(main)$ oping -c 1 www.torproject.org
PING www.torproject.org (2a01:4f8:fff0:4f:266:37ff:feae:3bbc) 56 bytes of data.
echo reply from www.torproject.org (2a01:4f8:fff0:4f:266:37ff:feae:3bbc): icmp_seq=1 timeout
--- www.torproject.org ping statistics ---
1 packets transmitted, 0 received, 100,00% packet loss, time 0,0ms
For what it's worth, iputils-ping doesn't have the same bug, but that's only because it defaults to IPv4 instead, which isn't ideal:
anarcat@marcos:~$ ping -c 1 www.torproject.org
PING www.torproject.org (38.229.82.25): 56 data bytes
64 bytes from 38.229.82.25: icmp_seq=0 ttl=57 time=29,997 ms
--- www.torproject.org ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 29,997/29,997/29,997/0,000 ms
anarcat@curie:~(main)$ ping -c 1 www.torproject.org
PING www.torproject.org (95.216.163.36) 56(84) bytes of data.
64 bytes from hetzner-hel1-03.torproject.org (95.216.163.36): icmp_seq=1 ttl=44 time=129 ms
--- www.torproject.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 128.706/128.706/128.706/0.000 ms
... but that's a different question.
the oping manpage specifically advertises IPv6 support this way:
In contrast to the fping utility (URL is listed in "SEE ALSO") oping can use both, IPv4 and IPv6 transparently and side by side.
And, for what that's worth, fping actually does the correct thing here:
anarcat@marcos:~$ fping -A -c 1 www.torproject.org
2604:8800:5000:82:466:38ff:fecb:d46e : [0], 64 bytes, 34.9 ms (34.9 avg, 0% loss)
2604:8800:5000:82:466:38ff:fecb:d46e : xmt/rcv/%loss = 1/1/0%, min/avg/max = 34.9/34.9/34.9
anarcat@curie:~(main)$ fping -A -c 1 www.torproject.org
116.202.120.165 : [0], 64 bytes, 112 ms (112 avg, 0% loss)
116.202.120.165 : xmt/rcv/%loss = 1/1/0%, min/avg/max = 112/112/112
(It should also be noted here that fping can use both IPv4 and IPv6 transparently, see the -m option, so the above quote is actually incorrect.)
note that this was originally filed as a Debian bug report (bug 1006224) but is forwarded here as a courtesy. thanks!