<div dir="ltr">icmp_timestamp has not been removed, and in Linux it is still present in the shared icmp code used by both IPv4 and IPv6.<div><br></div><div>More likely a bug that has never been noticed, because nobody bothered to test it.  I note that most icmp documentation doesn't even mention it's existence.</div><div><br></div><div>If a kernel bug, most likely a corrupted checksum.  But my bet would be code outright missing from the library.</div><div><div><br></div><div>Good luck!</div><div><br></div><div>Thanks,<div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr">--MM--<br>The best way to predict the future is to create it.  - Alan Kay<br><br>We must not tolerate intolerance;</div><div dir="ltr">       however our response must be carefully measured: </div><div>            too strong would be hypocritical and risks spiraling out of control;</div><div>            too weak risks being mistaken for tacit approval.</div></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 11, 2021 at 5:20 AM Sebastian Moeller via Rpm <<a href="mailto:rpm@lists.bufferbloat.net">rpm@lists.bufferbloat.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Two notes.<br>
1) Technically it is not OWD that is measured, but "OWD + unknown_offset", but since the goal is to evaluate the delta between the current delay and a history delay aggregate, the unknown offset does not matter too much, and as it turns out quite a lot of the tested reflectors are reasonably well synchronized already (to my utter, utter surprise).<br>
2) It appears that ICMPv6 removed the timestamp option, does anybody here have a link to the discussions that lead to this somewhat unfortunate decision?<br>
<br>
Best Regards<br>
        Sebastian<br>
<br>
<br>
> On Dec 11, 2021, at 13:59, Dave Taht via Rpm <<a href="mailto:rpm@lists.bufferbloat.net" target="_blank">rpm@lists.bufferbloat.net</a>> wrote:<br>
> <br>
> Somewhere in this thread the actual working method is buried, but:<br>
> <br>
> <a href="https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848/944" rel="noreferrer" target="_blank">https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848/944</a><br>
> <br>
> -- <br>
> I tried to build a better future, a few times:<br>
> <a href="https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org" rel="noreferrer" target="_blank">https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org</a><br>
> <br>
> Dave Täht CEO, TekLibre, LLC<br>
> _______________________________________________<br>
> Rpm mailing list<br>
> <a href="mailto:Rpm@lists.bufferbloat.net" target="_blank">Rpm@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/rpm" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/rpm</a><br>
<br>
_______________________________________________<br>
Rpm mailing list<br>
<a href="mailto:Rpm@lists.bufferbloat.net" target="_blank">Rpm@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/rpm" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/rpm</a><br>
</blockquote></div>