Nping – ping, but with a graph or table view
github.com
github.com
TCPPing: https://netbeez.net/blog/tcping/
vmPing: <https://netbeez.net/blog/how-to-use-vmping/>
DNSPing: <https://netbeez.net/blog/dnsping-linux/>
PathPing: <https://netbeez.net/blog/path-analysis-pathping-windows/>
fping: <https://netbeez.net/blog/linux-how-to-use-fping/>
gping: <https://netbeez.net/blog/linux-how-to-use-gping/>
prettyping: <https://netbeez.net/blog/linux-how-to-use-prettyping/>
https://www.google.com/search?client=firefox-b-e&q=smokeping...
If you have a network monitoring or asset system you can export IP addresses from, you should use a small glue script to automatically build a smokeping configuration. I've got one for our LAN and one for the WAN at each of our sites so I can track down issues at either level.
The LAN connection charts are a great daily sanity check, and the WAN connections (I have every-to-every for each site so any and all inter-site issues can be seen) can help keep your ISP honest with the service they're delivering.
For a while, largely related I think to just not having enough bandwidth at our office, but also partly because our coax on the Xfinity cablemodem was sketchy, we were not infrequently having issues, and the majority of my coworkers are on Windows. ping and tracert aren't very good tools for finding out what is going on with intermitant networking issues, especially when it might also be people's home wifi from WFH. There were times I just wished they could run mtr.
Over the last year or so I've been seeing more Windows tools available, which has been great!
• 2ping <https://www.finnie.org/software/2ping/>
• fping <https://www.fping.org/>
• hping <http://www.hping.org/>
• nping <https://nmap.org/>
• oping <https://noping.cc/documentation/oping/>
There’s also qping, tping and rping, but they are not implementing ping functionality, but are tools for checking the status of specific remote services.
apt-file search --regexp 'bin/.ping'
If I extend it to apt-file search --regexp 'bin/[^/]*ping$'
I also find:• smokeping <https://smokeping.org/>
The developer seems to be located in China. You are seeing the Great Firewall in action:
> The GFW does not have a unique technique of censorship. One of its strengths is to combine several techniques. One of them is the generation, by the network itself (and not by a lying resolver), of bogus DNS responses. You ask for a censored name and as a result you get an answer giving an IP address that has nothing to do with the question asked. [...] But if you ask him about a censored name, then the network generates a false answer. Even if the input is the same, the response varies from a request to another: [...]. The IP address 157.240.17.14 belongs to Facebook (normally scratch.mit.edu is at Fastly), a prime example of the lies generated by the GFW.
Why? It's just that Apple has CDNs in China. Yes, as long as you do all the bureaucracy nonsense and comply to censorship you can do that.
e6858.e19.s.tl88.net resolves to 221.194.154.187. tl88.net is the domain for a CDN vendor mainly operating in China.
And it does serve www.apple.com content with actual www.apple.com TLS cert.
They usually resolve to either other blocked websites to trigger a "dangerous website phishing" warning from the browser, or the ISP's own website pretending to be a captive portal.
One thing I've always wanted in a ping tool but never found is something that can log anomalous results, so for example one could leave it running in a screen/tmux session and come back a day or two later to not just see that there had been some instances of high latency or packet loss but also see when it happened and for now long per burst.
With all the existing tools I'm aware of I can come back to a long-running ping after a day or two and see that there were 170 pings that got lost but have no idea if that was individual intermittent drops or one continuous event like a cable modem rebooting in the middle of the night.
A couple of times I've attempted to do it myself but the nature of ICMP means it ends up requiring lower level programming than I'm comfortable with.
Bufferbloat is good thing to fix in general though and highlights why one should worry less about "how do single ICMP packets behave" and more about "how does actual loaded traffic of the protocol type I'm using behave in real usage". The results are often staggeringly different.
What does NB Ping mean?