Bug: [Multiping] The avg_rtt and min_rtt values are sometimes negative

[LGTH]

When I test the multiping function, I get the result below: xxx rtt: min[-4411.397] avg[-4411.397] max[0.0] lose_packet:0.5 packets_received:1 xxx rtt: min[-4625.375] avg[-3237.526] max[0.0] lose_packet:0.0 packets_received:2

Test Case like below:

network = '192.168.10.0/24'
net = ipaddress.ip_network(network)
hosts = []
for ip in net:
    hosts.append(str(ip))
res = multiping(hosts, count=2, timeout=1)
alive_host = []
for ip in res:
    if ip.is_alive:
        alive_host.append((ip.address, ip.avg_rtt))
        if ip.max_rtt < 0 or ip.min_rtt < 0 or ip.avg_rtt < 0:
            print("{} rtt: min[{}] avg[{}] max[{}]  lose_packet:{} packets_received:{}".format(ip.address, ip.min_rtt, ip.avg_rtt, ip.max_rtt, ip.packet_loss, ip.packets_received))

[ValentinBELYN]

Hi, thank you for taking the time to report your issue 👍

However, I don't understand how these values can be negative. Could you tell me:

• What is your operating system?
• Which version of icmplib are you using?
• Does the phenomenon reproduce systematically?
• Do you have the same results when you ping the same IP addresses?
• Finally, can you test with another computer?

Thank you in advance for your answers 😄

From my side, I just retested on different platforms and I do not encounter this problem.

[ValentinBELYN]

I hope my questions didn't scare you! 😄

[ValentinBELYN]

I close this issue because I don't think the problem comes from this library. Nothing could explain it at the code level. If you encounter this problem again, feel free to open a new issue.

[LGTH]

sorry, I see it now. 1.operating system is macos 2.icmplib==2.0.1

3. the phenomenon occur by chance But I think this issue can be closed, if i find the reason, I will back to write the reason

[tkoch96]

I'm having this issue as well..

[tkoch96]

Looking in ping.py here:

I see something special about Linux. This all makes me think requests and replies are not being mapped appropriately. I'm running the library as sudo. Is that a problem?

[ValentinBELYN]

Hi @tkoch96!

Sorry, I forgot to answer your question.

The identifier and the sequence number are used to match an ICMP request and a response. In the event that you execute several pings simultaneously (threads or others), you must make sure that the identifier used is different. Concerning the sequence number, it is automatically incremented by one by the library. So you don't have to worry about this number.

Why is there a difference when you run the library with or without privileges? When the library is run with root privileges and the privileged parameter is True, raw sockets are created. These sockets even intercept ICMP packets destined for other sockets. The identifier is therefore very important to link requests with the correct responses.

When using the library without privileges, DGRAM sockets are used. These sockets only receive the response associated with the request sent. This operation is handled by the Kernel automatically and therefore the identifier is of little use here. Otherwise, some systems such as Linux automatically replace this identifier with a random number.

I hope to have answered your question 😄

[tkoch96]

What you said makes sense, but the problem remains that I'm seeing negative RTTs. I was trying to probe ~4k addresses every ~20s using multiping. Worked fine on Windows.

[ValentinBELYN]

You encounter this problem on the ping or the multiping function or both?

[tkoch96]

In multiping

[ValentinBELYN]

Can you give me the parameters passed to the multiping function so that I can reproduce the phenomenon? By the way, what is your operating system and its version, as well as the version of icmplib?

Finally, can you install an older version of icmplib (1.2.2) and tell me if you still experience this behavior?

pip3 uninstall icmplib
pip3 install icmplib==1.2.2

Thanks 😃

[ValentinBELYN]

The multiping function will be completely rewritten in the next version. The bug you see will definitely be fixed. Therefore, I close this issue.