aisk/rust-ping

rust-ping's Issues

error on MacOS

io error: Operation not permitted (os error 1)

result in multi thread returns the same

runs in parallel, but I got the ping returns at the same time, what could be the problem

Minor typo crates.io

Hi,

At https://crates.io/crates/ping the title says "Simle and naive ping implementation in rust."

I think you meant to say "Simple and naive ping implementation in Rust."

I writing it here as I do not know where else to tell about it.

Internal error when pinging with dgram socket

As the title suggests, I am getting an internal error when calling ping::dgramsock::ping. I am not getting this error when running the raw socket version, but as the crate already suggests, that requires me to run the program with sudo.
I have been able to figure out where the error is coming from exactly, namely the last part of the ping function, that being the decoding of the response packet. The error in the decoding happens when checking whether the version is 4, this is because it is actually 0.

I do not know what this means, but that is what I managed to extrapolate. The data returned when using a dgram socket is the following:

00 00 A2 EF 00 07 00 01 2E DD 45 29 13 D0 DC 21
AA 78 A4 7D 84 B4 0D 0E 7D 66 2D C4 56 90 16 9C

I cannot provide the data returned when using a raw socket as getting CodeLLDB to run the program with sudo is a pain.

I am running the program on a Raspberry Pi 4B running Raspberry Pi OS Bookworm (Debian 12) 64 bit.

Concurrent pinging gives spurious results

Hello,

I am new to Rust and I am trying to ping multiple IP addresses at the same time using threads. When I use the ping crate sequentially, the result is as expected: IP addresses which are online yield Ok, IP addresses which are not online yield Err. However, when I try to ping multiple addresses concurrently, the behavior is "random", i.e., the return value from ping::ping does not reflect whether the address is available or not.

Minimal Example

Here is a minimal example:

use std::net::IpAddr;
use std::str::FromStr;
use std::thread;
use std::time::Duration;

use ping;

fn is_online(ip: IpAddr) -> bool {
    let timeout = Duration::from_millis(50);
    match ping::ping(ip, Some(timeout), None, None, None, None) {
        Ok(_) => { println!("{}: online", ip); true },
        Err(_) => { println!("{}: offline", ip); false },
    }
}

fn main() {
    let ips = [
        "192.168.178.1", // is available in my network
        "192.168.178.2", // is not available in my network
        "192.168.178.3", // is not available in my network
        "192.168.178.4", // is not available in my network
    ];

    let mut handles = vec![];
    for ip in ips {
        let addr = IpAddr::from_str(ip).unwrap();
        let handle = thread::spawn(move || {
            is_online(addr);
        });
        handles.push(handle);
    }

    for handle in handles {
        handle.join().unwrap();
    }
}

In my network, only 192.168.178.1 is available, but I see this output

192.168.178.2: online
192.168.178.4: online
192.168.178.3: online
192.168.178.1: online

or also this output:

192.168.178.1: online
192.168.178.2: offline
192.168.178.4: offline
192.168.178.3: offline

Additional Remarks

I have seen the exact same problem when I was using ping with tokio and green threads.

As said, I am new to Rust and maybe the code has some inherent logic error which I don't see. So please be forgiving if this is a stupid question. :-)

Version Information

I am using ping version 0.4.0 with rustc 1.67.1 (d5a82bbd2 2023-02-07).

Wrong echo response assumption

rust-ping wrongly assumes that the first package after a sent echo request always will be the response here:

rust-ping/src/ping.rs

Line 65 in e4b4432

socket.read(&mut buffer)?;

It may be the case that there are other ICMP packages in the same socket. [1]

A simple case where the next package received is not the reply is when you ping yourself. In that case the first package received is the just-sent echo request and not the reply. Therefore this crate will give a false negative on the ping-ability of a host.

Instead of assuming the response of a echo request is next package that arrives on the socket, this crate should listen on the socket and ignore any packages that do not match (instead of reporting an internal error) until the timeout ends. Of course Ok should be returned if a correct response is seen.

Please refer to the implementation of the the "normal" ping where the package is explicitly ignored in the ping4_parse_reply function: https://github.com/iputils/iputils/blob/1c081524ee463842631c708d060119ebc7ca699f/ping/ping.c#L1668 (I chose IPv4 as an example)

I do not have a suggested implementation yet. I have only just identified the issue right now.

[1] Not my words, see the "normal" ping implementation comments here: https://github.com/iputils/iputils/blob/1c081524ee463842631c708d060119ebc7ca699f/ping/ping.c#L1580

Release new version without failure dep

Heyo, it'd be nice to have a release that avoids the failure dep, as it is now unmaintained (and potentially unsound, though unlikely to appear in practice - rust-lang-deprecated/failure#336).