Hi, Installed it with cargo. (my os is 64 bit) when I do gping somehost I only see the blinking cursor in the top left. Normal ping works. Also tested it as root / with sudo. here is a demo video: https://youtu.be/RusyEIyL_K4

thread '<unnamed>' panicked at 'Error pinging: Unsupported OS Unknown', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/gping-0.1.6/src/main.rs:122:33

The newest release (1.1.0) fails on older Linux systems with the following error:

bridge ~/tmp [0:0]> gping bridge gping: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by gping)

This on a CentOS 7.7 box with latest updates installed.

CORRECTION: It's on CentOS 7.9 and affects also gping 1.0.1.

This introduces a data structure that replaces Vec<(f64, f64)> so that it does not perform a shift left at every push when its at full capacity. This should introduce performance benefits when the buffer is large enough. Additionally, this data structure performs better the larger the buffer size.

Signed-off-by: Hanif Bin Ariffin [email protected]

Instead of full screen, it'd be awesome if gping could occupy like 7 lines of text, and remain visible after ^C. Then people could scroll up and skim data from earlier runs.

I faked this screenshot:

If I start gping for local devices (192.168.1.*/24) it works fine. but if I try such as gping google.com I get the following error.

Traceback (most recent call last):
  File "/usr/local/bin/gping", line 9, in <module>
    load_entry_point('pinggraph==1.0', 'console_scripts', 'gping')()
  File "/usr/local/lib/python2.7/dist-packages/gping/pinger.py", line 313, in run
    _run()
  File "/usr/local/lib/python2.7/dist-packages/gping/pinger.py", line 343, in _run
    plotted = plot(width, height, buff, host)
  File "/usr/local/lib/python2.7/dist-packages/gping/pinger.py", line 181, in plot
    u"█", column + 2, 2, 2 + bar_height, paint=_paint
  File "/usr/local/lib/python2.7/dist-packages/gping/pinger.py", line 72, in vertical_line
    self[column, y] = (next(data_iter), paint)
StopIteration

How can I make it work? Thanks

pinger got accepted into debian yesterday. Because of that I noticed that the some of the tests fails on the i386 arch because of minor time differences:

running 10 tests
test linux::tests::test_linux_detection ... ok
test test::tests::alpine ... ok
test test::tests::android ... ok
test test::tests::debian ... ok
test test::tests::dragonfly ... FAILED
test test::tests::freebsd ... FAILED
test test::tests::netbsd ... FAILED
test test::tests::openbsd ... FAILED
test test::tests::ubuntu ... FAILED
test test::tests::macos ... FAILED

failures:

---- test::tests::dragonfly stdout ----
thread 'test::tests::dragonfly' panicked at 'assertion failed: `(left == right)`
  left: `"110.394ms"`,
 right: `"110.395ms"`: Failed at idx 3', src/test.rs:31:17
stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:181:5
   4: pinger::test::tests::test_parser
             at ./src/test.rs:31:17
   5: pinger::test::tests::dragonfly
             at ./src/test.rs:55:9
   6: pinger::test::tests::dragonfly::{{closure}}
             at ./src/test.rs:54:5
   7: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   8: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- test::tests::freebsd stdout ----
thread 'test::tests::freebsd' panicked at 'assertion failed: `(left == right)`
  left: `"110.394ms"`,
 right: `"110.395ms"`: Failed at idx 3', src/test.rs:31:17
stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:181:5
   4: pinger::test::tests::test_parser
             at ./src/test.rs:31:17
   5: pinger::test::tests::freebsd
             at ./src/test.rs:50:9
   6: pinger::test::tests::freebsd::{{closure}}
             at ./src/test.rs:49:5
   7: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   8: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- test::tests::netbsd stdout ----
thread 'test::tests::netbsd' panicked at 'assertion failed: `(left == right)`
  left: `"110.394ms"`,
 right: `"110.395ms"`: Failed at idx 3', src/test.rs:31:17
stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:181:5
   4: pinger::test::tests::test_parser
             at ./src/test.rs:31:17
   5: pinger::test::tests::netbsd
             at ./src/test.rs:65:9
   6: pinger::test::tests::netbsd::{{closure}}
             at ./src/test.rs:64:5
   7: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   8: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- test::tests::openbsd stdout ----
thread 'test::tests::openbsd' panicked at 'assertion failed: `(left == right)`
  left: `"110.394ms"`,
 right: `"110.395ms"`: Failed at idx 3', src/test.rs:31:17
stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:181:5
   4: pinger::test::tests::test_parser
             at ./src/test.rs:31:17
   5: pinger::test::tests::openbsd
             at ./src/test.rs:60:9
   6: pinger::test::tests::openbsd::{{closure}}
             at ./src/test.rs:59:5
   7: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   8: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- test::tests::ubuntu stdout ----
thread 'test::tests::ubuntu' panicked at 'assertion failed: `(left == right)`
  left: `"19.399ms"`,
 right: `"19.4ms"`: Failed at idx 2', src/test.rs:31:17
stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:181:5
   4: pinger::test::tests::test_parser
             at ./src/test.rs:31:17
   5: pinger::test::tests::ubuntu
             at ./src/test.rs:70:9
   6: pinger::test::tests::ubuntu::{{closure}}
             at ./src/test.rs:69:5
   7: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   8: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- test::tests::macos stdout ----
thread 'test::tests::macos' panicked at 'assertion failed: `(left == right)`
  left: `"33.897ms"`,
 right: `"33.898ms"`: Failed at idx 2', src/test.rs:31:17
stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
             at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:181:5
   4: pinger::test::tests::test_parser
             at ./src/test.rs:31:17
   5: pinger::test::tests::macos
             at ./src/test.rs:45:9
   6: pinger::test::tests::macos::{{closure}}
             at ./src/test.rs:44:5
   7: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   8: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


failures:
    test::tests::dragonfly
    test::tests::freebsd
    test::tests::macos
    test::tests::netbsd
    test::tests::openbsd
    test::tests::ubuntu

test result: FAILED. 4 passed; 6 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.04s

This looks like a bug to me as all other arches don't have this problem. I'd suggest to maybe even add a [#cfg] macro to run the bsd/macos test only on their respective platform.

Hello, I'm sorry if my question seems silly but, in the installation doc the repository is "buster", does that mean that qping can't be installed on "bullseye"?

Thx

$ cargo install gping

error[E0658]: use of unstable library feature 'matches_macro'
  --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.12.0/src/backend/crossterm.rs:58:17
   |
58 |             if !matches!(last_pos, Some(p) if x == p.0 + 1 && y == p.1) {
   |                 ^^^^^^^
   |
   = note: for more information, see https://github.com/rust-lang/rust/issues/65721

error[E0599]: no associated item named `MAX` found for type `usize` in the current scope
   --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.12.0/src/buffer.rs:275:47
    |
275 |         self.set_stringn(x, y, string, usize::MAX, style);
    |                                               ^^^ associated item not found in `usize`
    |
help: you are looking for the module in `std`, not the primitive type
    |
275 |         self.set_stringn(x, y, string, std::usize::MAX, style);
    |                                        ^^^^^^^^^^^^^^^

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0599, E0658.
For more information about an error, try `rustc --explain E0599`.
error: could not compile `tui`.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `gping v0.1.7`, intermediate artifacts can be found at `/tmp/cargo-install5Kz6Qu`

Caused by:
  build failed

~ brew install gping ==> Searching for similarly named formulae... Error: No similarly named formulae found. Error: No available formula or cask with the name "gping". ==> Searching for a previously deleted formula (in the last month)... Error: No previously deleted formula found. ==> Searching taps on GitHub... Error: No formulae found in taps.

try brew tap also failed

Using master (commit b2aecf2) I get the following error when trying to run setup.py:

sudo ./setup.py from: too many arguments ./setup.py: 4: ./setup.py: Syntax error: newline unexpected (expecting ")")

It's probably user error on the installation but snap and pip aren't an option for me.

Running Ubuntu 16.04.3 LTS x86-64 Python colorama 0.3.7 installed

I noticed that gping crate page wasn't showing the readme. I looked at the serde source tree and they handle it like this so should work here too in theory.

I'm fairly sure this was working before, it appears a recent version of gping broke the ability to ping IPv6 addresses.

For example running the command:

gping 2001:db8::1

It responds with the error:

There was an error running ping: exit status: 68
                                                Stderr: ping: cannot resolve 2001:db8::1: Unknown host

I'm running version 1.6.3

gping 1.6.3
commit_hash: 
build_time: 2022-12-20 21:21:34 +00:00
build_env: rustc 1.65.0,

For Reasons I was looking at the source code for this crate, and I found code like this:

    fn ping_args(&self, target: String) -> Vec<String> {
...
        if let Some(interface) = &self.interface {
            args.push("-I".into());
            args.push(interface.clone());
        }
        args.push(target);

This is unsound, because if target starts with a - it will be interpreted by ping as an option. (By unsound I mean this: if this API is passed untrusted input, undesirable malfunctions, which might be security relevant, can occur.)

I don't think this is very exploitable, on Linux at least, because almost all of the options also require a target, which when this malfunction occurs won't be supplied. The worst that can be done seems to be to pass -V or -h and cause the rest of the pinger library to try to parse the help or version output, which will be a malfunction, but fairly harmless.

I suggest that the ping_args function ought to take something like target: SyntaxCheckedTargetHost (with struct SyntaxCheckedTargetHost(String) and then in the common code you would check that the thing starts with an alphanumeric or [ or : when constructing the SyntaxCheckedTargetHost.

Thanks,.

Hello,

I don't know what to trust, but the gping shows something different than ping command with 0.25s interval From what I understand when there is no response from the server for about 2s Gping adjust chart to that timeframe but then it does not go back displaying 300ms as few seconds latency. Gping version 1.3.1

Here is the Video showing the problem the problem starts at 0:45 https://youtu.be/nMdM5CtExrU

According to this the "max" is 37ms, but looking at the graph we can clearly see several spikes up into 50ms range. The demo gif in the README.md has this same problem.