Latency Module

[Hi0Rizvi]

This will add 16 bytes additional payload to find the latency. The idea is to attach the current timestamp and destination IP with the payload. We can use the payload timestamp and packet capture timestamp to find the latency. The destination is useful to match the actual target IP and evaluate any address translation.

[Woutifier]

Hey Rizvi! Looks pretty good. Do you have the counterpart for the receiving end as well? Did you run this and compared the number of responses (I suspect that a bigger payload leads to a lower fraction of responding hosts, but I think with this we are still below that limit).

In another version of this (at https://github.com/Woutifier/verfploeter) I've also included an HMAC in the packet payload to detect any tampering. Maybe interesting to also bring that into version.

[Woutifier]

It's also possible to optimize (reduce) the number of bytes used for the latency, as we don't really need to know how many nanoseconds passed since the unix epoch, but rather the number of milliseconds (or microseconds) since the echo request was sent which was most likely within the past hour or so. Maybe not necessary for this version, but something to keep in mind.

[Hi0Rizvi]

Hi Wouter, Sorry for the late reply, somehow I missed it. I actually did not find any significant difference in the number of replies. I will check it and will let you know the exact number.

[Hi0Rizvi]

Hello @Woutifier,
It looks like I am getting the same number of replies with or without 20 bytes of timestamp payload. I tested with 2000 packets/s. So, I think there is no blocking from the targets. But there could be rate-limiting from the prober's end as we are sending 20 bytes larger packets each time. If we use a rate of 5000 packets/s, it would make ~1Mb/s extra traffic.

[Woutifier]

Nice sounds good!

[Woutifier]

let me know when you want me to merge this!