Bug: RTT is incorrect for IPv6 Packets
lemoer opened this issue · comments
Hi there,
having two separate timeouts for IPv4 and IPv6 is not a good idea. In the worst case, the IPv4 socket will block until the timeout is due and only then the _sock6.recv()
is called. This leads to incorrect RTT values for IPv6 packets.
The worst case can be easily observed if only IPv6 nodes are pinged. As no IPv4 responses arrive, the sock.recv()
blocks until the timeout is due. Here is an example:
import multiping
mp = multiping.MultiPing(["2001:4860:4860::8888"])
mp.send()
mp.receive(30)
({'2001:4860:4860::8888': 33.48264455795288}, [])
As you can see, multiping said, that the response was after ~33 seconds.
lemoer@orange ~ [1]> sudo tcpdump -n -i wlp3s0 host 2001:4860:4860::8888
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:33:44.109704 IP6 .......... > 2001:4860:4860::8888: ICMP6, echo request, seq 0, length 16
02:33:44.169743 IP6 2001:4860:4860::8888 > ..........: ICMP6, echo reply, seq 0, length 16
Observing the scenario in tcpdump reveals that this is not true and the response was already there in a couple of microseconds.
As I am only expecting IPv6 hosts in my current usecase, I wrote this small patch that disables the IPv4 loop, when only IPv6 destinations are pinged. However this is not a suitable approach for upstream. I suggest using poll()
here.
Kind regards,
lemoer