Thats sad, but not my fault.

Anyway.

If you use the lib in your project, simply do things as this (c# syntax):

var response = await Icmp.Ping("1.1.1.1", 64, 3000, true, cts.Token);

OR

var response = await Icmp.Ping("one.one.one.one", 64, 3000, true, cts.Token);

OR

var response = await Icmp.Ping("2606:4700:4700::1111", 64, 3000, true, cts.Token);

The method Ping(...) runs asynchron, so it´s in your app-code to await the things. Later i will implement a synchronous variant (internal async)

The method parameters are:

• ipOrHostName - string - as described, the ip or hostname of the host to ping
• ttl - int - it´s not a time but more a number of max hops to the host to ping. Its very usefull for traceroutes.
• receiveTimeout - int - timespan in ms when the packet is send and no pong returned back
• dontFragment (optional) - bool - if the frame too big, split it in multiple packets. Attention! This thing does not run with MacOS
• token - CancellationToken - The token, when the async process is cancelled (async can theoretically runs for ever and that ist not the goal). Attention! The token value should be higher than the receiveTimeout value because it cancel the async process before the receiveTimeout is reached!

The result is much more comprehensive than the std OS-Ping or the dotnet core ping, which use the std-OS-Ping. If you don´t believe this, rename your ping command and try to run the dotnet core ping. It says: No ping command found. Lets look at the result.

To fetch some results i've written a small app, that use lib and show the results on console.

Here are some results. All results are fetched from a linux os (kubuntu 21.10).

So, let's interpret the result:

• Code -> is the response code value from the ping socket result byte[1] in returned datagram
• AddressFamily -> internal calculation of with which protocolfamily the ping is sended (ipv4 or ipv6). It depends on your network settings and with which hostOrIpAddress you ask.
• TTL -> response time to live. It is not a time, mor the amount of hops from returned host to your client. The value you give to se ping has the same behavior but it is not the same result from the response. It is very usefull, if you would build up a traceroute. For more informations about ttl see here: https://de.wikipedia.org/wiki/Time_to_Live#:~:text=In%20IPv6%20wurde%20die%20TTL,der%20maximal%20m%C3%B6gliche%20Wert%20255.
• FromIp -> Is the Ip-Address from which the client sends the ping command. It must not be a public address
• Origin -> That is the IP-address from the answering host. It could be a different one, if the sended ttl is lower then the hops to host.
• Type -> The response type as 8bit field. it is different from ipv4 to ipv6
• TypeString -> The response type as written text (from rfc-792 page). EchoReply means, that the answered host ist the asked host.
• Identifier -> only ipv4
• Sequence -> only ipv4
• Checksum -> only ipv4
• PayloadSize -> the size of the datagram which comes from host.
• Data -> The byte array of the datagram. It is that, what the Socket read from the host. It is more a debugging feature. All the values from that array are encapsulated in the appropriate fields.
• RoundTripTime -> the time from sending the packet to the host and receive the answer.

Let's do a little different ping: var response = await Icmp.Ping("1.1.1.1", 64, 3000, cts.Token);

We change the ip address to an ipv4 one. And let's see what happened:

Aha, we receive some more results. In the following, there are only the changed results described:

• AddressFamily -> ok, we ping in ipv4 manner
• TTL -> The pinged host send us a value how many hops he is away from our client. This one must interpreted as 64 - 58 = 6 + 1 Why + 1? In this case the pinged host does'nt know about our internal network. He knows only our public router. If you have a very complicated company net with a lot of internal routing, the value could be much higher. Probably I think, this could be the reason, why the response ttl does not work with ipv6. With an ipv6-address, the client is able to be the endpoint, there is no network router. Same goes for intermediate hops.
• Type -> Aha, in ipv4 the Type for a valid echo reply is 0 (in ipv6 it is 129). The other changed things are more debugging things and i did'nt explain that. See in the rfc-792 if it is importand for you.

And now, let's do a funny thing. var response = await Icmp.Ping("1.1.1.1", 3, 3000, cts.Token);

We change the ttl from 64 to 3. Let's look to the result:

Now, you could see how traceroute work. We limit the ttl to the host to 3. The max amount of hops to the pinged endpoint 1.1.1.1 is 3. As we know from the foreign result that the amount of hops to 1.1.1.1 is in minumum 7 from our client, we never reached the asked endpoint! But we reached the 3rd hop (endpoint) of this route. In my case it is: 89.1.16.161

And what is the context with traceroute?

Ok, lets look.

If we wrote a small app, that chain (e.g. from 1 to 30) and ping so long, until the type is EchoReply?

It could be a simple for-each-loop.

With the response endpoint of every intermediate step and the roundtriptime, you receive every hop from your client to the host.

Nothing more does traceroute do.

Very nice, indeed?

And now, let's check if this could be a real scenario and use the ping from the operating system and check this:

The lib does exactly the same things as the os ping do. But now, we have all the funny results in our app.

The returned type (and TypeString) comes also back correctly. In this case it is 11 (TimeExceeded)

Wonderful.

Update 2022-01-20

As described above, traceroute is simply a chain of pings where the ttl-value is increased by 1 for every hop, until the origin endpoint is reached. I changed the ordinary test ping method and enhance this thing a little bit.

Lets explain some things. We build up a while-loop. The loop ends, when

• the max hop count (30 per default for the most traceroute implementations) is received
• the state of the result is 0 for ipv4 or 129 for ipv6 which means EchoReply (or endpoint reached).
• the try catch block inside the loop, brings up a possible exception (mostly token cancellation, if the pinged host drops icmp packages)

I set the cancellation token inside the loop, so in every loop step the token time where reset. I set the cancellation token time to a very high amount (you can make that configurable for your own purposes), to receive long running neighbor things. I put away some unused debug information and format the return a little bit (one liner and so on) Let's do some tests.

First with an ipv4 ip address 1.1.1.1

Wow, that looks pretty cool! And yes, i have a DSL-Connection, but this thing ist very fast. Let's use the ordinary traceroute from linux and make a check:

Parameters are:

-I --> use ICMP (instead of tcp 80)

-n --> don't resolve Ip addresses

-q 1 --> make 1 request (instead of 3)

OK, very impressive.

Let's try another one:

Traceroute to heise.de (a german it-magazine)

Aha, nice types with a spooky fe80 local address from an internet hop. At now, i can't say what neighbor Advertisement say, but, it looks impressive.

And now the check with the ordinary traceroute:

The new parameter -6 is, because without this traceroute does a ipv4 call.

Oops, whats that? #7 is marked with a star (not resolvable)? But there are results...btw. in my resultset.

And here is a check, that the exception handling works as expected.

Conclusion

With some lines of code, we build a simple traceroute function, that work with all os`s (linux, windows or mac or docker or what ever).