Best PING, one that understands "TTL expired in transit"?

[Ola_A]

I wrote a simple network monitor that uses the "ping %s -n %d -w %d" windows command line command as suggested in for example:

https://forums.ni.com/t5/Example-Programs/Native-LabVIEW-Host-or-IP-Ping-Using-LabVIEW/ta-p/3511264

But this ping wrongly sais ok if there is an ping error "TTL expired in transit", same problem exists in windows command line,  see screnshot.

I find several suggestions if I search for "ping" in the forums, which one shall I use to avoid this problem?

By the way most humans interprets this error wrongly also, I know from own experience!

/Ola

[GerdW · Accepted solution]

Hi Ola,

all you need to do is to improve the parsing of the PING result. (Right now only the IP is parsed.)

Why don't you check for any errors like "TTL expired"?

[Intaris · Accepted solution]

I don't see the word "ok" anywhere in the ping result.

Technically, everything is correct as it is shown.  Four requests sent, four answers received.  Zero lost packages.

It's up to you to detect the "TTL expired" case.

[ikaiser]

Although your answers seem to contradict, all of you are correct. ping is the correct tool to generally check if there is a route to a host. It can also do some metrics, but it cannot assess if a route makes sense:

$ ping -i 1 8.8.8.8

Here I expect my TTL to expire in transit. However, this message still means there is a route to that remote host found (no evidence about if it actually works).

-> everything is fine, despite the message

$ ping -i 128 8.8.8.8

(same as ping 8.8.8.8)

Here I'd expect a full round-trip of the icmp packet. If you see "TTL expired in transit", you most likely have a looped route or are missing a vlan configuration one side of a trunk port. The remote host will never be reached.

-> you need some network troubleshooting

[Ola_A]

Ok, I'll improve the parsing of the resulting text then. But if feels a little to hacky to be good practise.

I remember a similar case when I did something clever that broke since the output in command line was different in windows xp/7 or different in swedish/english/japanese or whatever.

But this tool is only for my personal use, so that should be ok.

ikaiser, you are correct that it exist some network loops or something, and I try to figure out when and why it happens.

Thanks for all answers!

[rolfk]

Of course, parsing the text output of a command line tool is always tricky as that output can and often is dependent on OS version, and definitely currently selected language setting. That's in the nature of the beast.

The alternative is to directly interface to the OS API. Problem here is that this is very dependant on OS and OS version.

Since Windows 2000 there exists some preinstalled ping service but the API to it was completely undocumented until Windows 7.

https://docs.microsoft.com/en-us/windows/desktop/api/icmpapi/nf-icmpapi-icmpsendecho

This is the WinAPI for that service. While it can be accessed with the LabVIEW Call Library Node, it is non-trivial to do so. For the faint hearted using some .Net nodes is probably the much easier alternative.

The alternative was to use raw sockets to create your own ping handler directly on top of IP frames, but the bad thing about this is that raw sockets are only available for priviliged processes, meaning they either need administrator rights together with being elevated since Windows Vista or a Policy change in the registry to allow raw socket access, which you only want to give to very specific processes as otherwise every virus can run havoc with your machine.