Not all versions of ping binary support float/double type numbers for the timeout flag

[danteCarvalho]

When i try yo run this on ubuntu 20.04

var ping = Ping(ip, count: 5);
ping.stream.listen((event) {
print(event);
});

the print(event); is never called

[✓] Flutter (Channel beta, 2.2.0-10.1.pre, on Linux, locale en_US.UTF-8)
• Flutter version 2.2.0-10.1.pre at /home/dante/a/flutter
• Framework revision 0941968447 (6 days ago), 2021-04-15 12:01:02 -0700
• Engine revision d2a2e93510
• Dart version 2.13.0 (build 2.13.0-211.6.beta)
[✓] Linux toolchain - develop for Linux desktop
• clang version 10.0.0-4ubuntu1
• cmake version 3.16.3
• ninja version 1.10.0
• pkg-config version 0.29.1

[point-source]

Can you call print(ping.command); before calling listen and then run the command it outputs in your local terminal to ensure the syntax is being correctly built? Perhaps there is an error that isn't being caught by dart_ping.

I just tried running the example code (very similar to yours) on my own ubuntu (20.10) machine and it seems to be working for me.

[danteCarvalho]

ok with this
final ping = Ping('google.com', count: 5);

      // [Optional]
      // Preview command that will be run (helpful for debugging)
      print('Running command: ${ping.command}');

      // Begin ping process and listen for output
      ping.stream.listen((event) {
        print(event);
      });

the output was: flutter: Running command: ping -O -n -W 2.0 -i 1.0 -t 255 -c 5 google.com
i tryed running this on the terminal: ping: bad linger time: 2.0

edit: removing the decimals worked: ping -O -n -W 2 -i 1 -t 255 -c 5 google.com

ping version
ping -V
ping from iputils s20190709

[point-source]

You are awesome. I started typing this reply 3 times asking for additional info and just as I was about to send, you would edit your post with exactly the info I was about to ask for. Thanks for making my job easy!

Anyway, this is a fascinating issue. I just booted an ubuntu 20.04 docker container and tested with the same ping version you appear to be using and I cannot reproduce the issue. See here:

root@1dfebb87de59:/# ping -V
ping from iputils s20190709
root@1dfebb87de59:/# ping -O -n -W 2.0 -i 1.0 -t 255 -c 5 google.com
PING google.com (142.250.188.238) 56(84) bytes of data.
64 bytes from 142.250.188.238: icmp_seq=1 ttl=115 time=17.6 ms
64 bytes from 142.250.188.238: icmp_seq=2 ttl=115 time=64.3 ms
64 bytes from 142.250.188.238: icmp_seq=3 ttl=115 time=55.3 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 17.617/45.722/64.301/20.214 ms
root@1dfebb87de59:/# 

Still, it's clear the issue does exist. So my options are:

1. Remove the timeout flag unless it's explicitly set by the user (but this reduces consistency across platforms and still doesn't fix the problem for anyone with your version of ping who wants to use that flag)
2. Change the timeout flag from a double to an int to force whole numbers (reduces flexibility on most platforms)
3. Identify when the double is a whole number and cast it to int just in case (preserves flexibility but will still error if someone like yourself happens to set a decimal)

Thoughts?

[danteCarvalho]

I guess the problem has something to do with this: https://github.com./iputils/iputils/releases

Incompatible changes

Handling numeric options changed
ping: use '.' (dot) as a decimal separator regardless locale (for -i/-W
options). Since s20121121 till s20190709 decimal separator for -i option
depended on locales ($LC_NUMERIC), but only when compiled with USE_IDN=yes.

my $LC_NUMERIC is: declare -x LC_NUMERIC="pt_BR.UTF-8"

I guess number 2 is the best option, or.... if the timeout flag fails with decimal, catch the exception and change it to int

edit: oh and i had to remove the decimals from the -i and from -W

[point-source]

I just pushed 6.0.0 which uses int instead of double. We'll see if anyone complains ;)

If this change works for you, let me know or close the issue once you've tested. Thanks!

[danteCarvalho]

Thanks a lot!!!! it works very well now =). If someone complains, well, you can try that thing, catching the exception and change to int.

[danteCarvalho]

Now, would you venture in trying to make the web version working? there are some javascript codes that says they can ping.

[point-source]

If you can link them to me, I am happy to take a look but last I checked, it seems browsers are not granted access to the underlying network utilities / layers

[danteCarvalho]

Well i dont know how these works nor how npm works but these 3 seems the most promising
https://www.npmjs.com/package/icmp
https://www.npmjs.com/package/net-ping
https://www.npmjs.com/package/ping

some codes that i saw on stackoverflow just try to fake a ping downloading a img or something.

[point-source]

Yeah all of these are for nodejs, which is a javascript runtime for servers. In other words, these are built for running directly on a machine, not in a browser on client side. They won't work if you try to import them in a webpage.

As for the img method, I've seen stuff that tries to open a connection to another site as a means to "ping" from a webpage but most websites these days implement cors as a security measure and that would prevent this method from working reliably. Additionally, it wouldn't be able to access any local network resources due to browser security restrictions. So the only sites that would actually show as online are sites that are poorly secured and sites that are designed specifically to be accessible by other sites (for example, for the purpose of being embedded, like a cdn).

May I ask what your use case for browser based ping is? Maybe I can help come up with a workaround.

[danteCarvalho]

Oh i see, i thought that if its javascript it would work. nothing we can do i guess.

About the use case, i was just trying to make my app the same in all builds, android, web, etc. But i can live without the ping on web.

The use is this green/red bar.

if the first half is green it means the ping worked on the ip/computer. If the second half is green it means the the http request i sent the server in that computer worked and that the server is on.

When i am i the web i just show the second bar as if it was just one.

[point-source]

Ah, yeah that makes sense. Probably just catching a failed request is the best you can do in a browser. At least that I'm aware of.