Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

oping should failover correctly to IPv4 #68

Open
anarcat opened this issue Feb 21, 2022 · 1 comment
Open

oping should failover correctly to IPv4 #68

anarcat opened this issue Feb 21, 2022 · 1 comment

Comments

@anarcat
Copy link
Contributor

anarcat commented Feb 21, 2022

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

@anarcat
Copy link
Contributor Author

anarcat commented Feb 21, 2022

note that this was originally filed as a Debian bug report (bug 1006224) but is forwarded here as a courtesy. thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant