<div dir="ltr">In case others wind up here, the issue described here appears to be addressed by "libpcapng: fix timestamp wrapping in output files".  Thanks for the patch!<div><br></div><div><a href="https://patches.dpdk.org/project/dpdk/patch/20220517100115.157888-1-quentin@armitage.org.uk/">https://patches.dpdk.org/project/dpdk/patch/20220517100115.157888-1-quentin@armitage.org.uk/</a><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 14, 2022 at 11:15 AM Stephen Hemminger <<a href="mailto:stephen@networkplumber.org">stephen@networkplumber.org</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">On Thu, 13 Jan 2022 21:38:06 -0500<br>
Ben Magistro <<a href="mailto:koncept1@gmail.com" target="_blank">koncept1@gmail.com</a>> wrote:<br>
<br>
> While utilizing dumpcap with our app, we have observed the captured file<br>
> producing out of order timestamps to include negative times.  We are still<br>
> investigating the root cause but believe it is in lib/pcapng.  While doing<br>
> some testing of this issue, this behavior was not observed with pcap.  In<br>
> the attached pcap, there are 5 streams (same curl multiple times a few<br>
> seconds apart), with streams 1 and 3 showing oddities.  Specifically,<br>
> stream 1 is in the future relative to the packet order and stream 3 has a<br>
> negative time.<br>
> <br>
> Not sure if the pcap file will actual post/attach, if it doesn't will try<br>
> something.<br>
> <br>
> System: CentOS7 + devtoolset 9<br>
> DPDK: v21.11<br>
<br>
The library hast convert from TSC (cpu clock) to nanoseconds since 1/1/1970<br>
The function pcapng_init computes the offset. <br>
</blockquote></div>