From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7BAE4A0548; Thu, 2 Jun 2022 18:34:21 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1DECD40694; Thu, 2 Jun 2022 18:34:21 +0200 (CEST) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by mails.dpdk.org (Postfix) with ESMTP id 27FBA40691 for ; Thu, 2 Jun 2022 18:34:20 +0200 (CEST) Received: by mail-wr1-f52.google.com with SMTP id u3so7156688wrg.3 for ; Thu, 02 Jun 2022 09:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yRUQe0r/lWcfdX9/JA4DvXllGM9+0Zlcrkvj18s+Zqo=; b=cUGGMLb7bCUIWgtMaUfI/WnPy59wkeO2TGq3dNAoX/QMeRGcNx9lcVZ+YNLCAlckby 4nQpOnyn/1n73mYOgkUvgbo9YoklLKi8pQLVnLA2kB+vbacwPPnm9pGyrM+UROcksKct NeYo9REnc8TsVKSs/GPbrG57k36scmQhDb/ydGM0rudMktx1L9ftgowNpZU2cO9Nn0Sm A/BxX0Q1wFmbYGsZLt649V7pccDUYs7AEq8fLYpmufBQyGlkY+2PmcEKjUKpngDYjqIe m4AjK01LHpXtogBAcpPIgPuu3OXSlW6sc/3cuRuCRr+GZb1m/1/moh6aMOSDEpKmHfFI e1UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yRUQe0r/lWcfdX9/JA4DvXllGM9+0Zlcrkvj18s+Zqo=; b=eZ41H2hYUUtQiMcHWxTkxJFsNjouAVtK06was3n4wy/ABQVFW1iqwnGkfc5+07uAT8 HHjOVzmbi1bHJ4Dvga5g/oTO3Y0XDFgAV3hZ0X1JO0z3UEeFodnIPrbmD/16bu8y4iot JSC6jS2RF3ZfFymQRkwckLZzLCsfEsN83ne+yC2FQ1xW4D8xwxHgD+yeiZLaYbMlur64 5OKaIPArbimWoOuLyIEFPAzoPRH8YyMuUGI/LcDd5DukPJd8Qy44CWwiN9Q5ALhlicAv tX8RU4CZtR8xu+FfFhdswvl96zbpDs6d15qxcrCY3Mi1dI1bnsYJbza0XJxf1fs93fSW izbA== X-Gm-Message-State: AOAM531tJOfn3TN3TMcg0q5hXv4wVORzh09VDJeutKjj/iD6eKtFrthP ZNmblbS/TCXGQPAzEz8WALKP84LCOnFnXcI3j64= X-Google-Smtp-Source: ABdhPJy4gE2pNOr3CHO+5KS7wTsnDrZeSHWaGEb9TJB0xm3MSiA+poc5AtUaVzyN9NhFjA/ndGhmSZn0g+eI1KOBIT0= X-Received: by 2002:a05:6000:782:b0:20f:ca42:c4f0 with SMTP id bu2-20020a056000078200b0020fca42c4f0mr4379653wrb.691.1654187659733; Thu, 02 Jun 2022 09:34:19 -0700 (PDT) MIME-Version: 1.0 References: <20220114081547.2ebce3b2@hermes.local> In-Reply-To: <20220114081547.2ebce3b2@hermes.local> From: Ben Magistro Date: Thu, 2 Jun 2022 12:34:08 -0400 Message-ID: Subject: Re: dumpcap w/ pcapng produces out of order/negative times To: Stephen Hemminger , quentin@armitage.org.uk Cc: dev@dpdk.org, ben.magistro@trinitycyber.com Content-Type: multipart/alternative; boundary="000000000000d9b00905e0799358" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000d9b00905e0799358 Content-Type: text/plain; charset="UTF-8" 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! https://patches.dpdk.org/project/dpdk/patch/20220517100115.157888-1-quentin@armitage.org.uk/ On Fri, Jan 14, 2022 at 11:15 AM Stephen Hemminger < stephen@networkplumber.org> wrote: > On Thu, 13 Jan 2022 21:38:06 -0500 > Ben Magistro wrote: > > > While utilizing dumpcap with our app, we have observed the captured file > > producing out of order timestamps to include negative times. We are > still > > investigating the root cause but believe it is in lib/pcapng. While > doing > > some testing of this issue, this behavior was not observed with pcap. In > > the attached pcap, there are 5 streams (same curl multiple times a few > > seconds apart), with streams 1 and 3 showing oddities. Specifically, > > stream 1 is in the future relative to the packet order and stream 3 has a > > negative time. > > > > Not sure if the pcap file will actual post/attach, if it doesn't will try > > something. > > > > System: CentOS7 + devtoolset 9 > > DPDK: v21.11 > > The library hast convert from TSC (cpu clock) to nanoseconds since 1/1/1970 > The function pcapng_init computes the offset. > --000000000000d9b00905e0799358 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In case others wind up here, the issue described here appe= ars to be addressed by "libpcapng: fix timestamp wrapping in output fi= les".=C2=A0 Thanks for the patch!


On Fri, Jan 14, 2022 at 11:15 A= M Stephen Hemminger <steph= en@networkplumber.org> wrote:
On Thu, 13 Jan 2022 21:38:06 -0500
Ben Magistro <ko= ncept1@gmail.com> wrote:

> While utilizing dumpcap with our app, we have observed the captured fi= le
> producing out of order timestamps to include negative times.=C2=A0 We = are still
> investigating the root cause but believe it is in lib/pcapng.=C2=A0 Wh= ile doing
> some testing of this issue, this behavior was not observed with pcap.= =C2=A0 In
> the attached pcap, there are 5 streams (same curl multiple times a few=
> seconds apart), with streams 1 and 3 showing oddities.=C2=A0 Specifica= lly,
> stream 1 is in the future relative to the packet order and stream 3 ha= s a
> negative time.
>
> Not sure if the pcap file will actual post/attach, if it doesn't w= ill try
> something.
>
> System: CentOS7 + devtoolset 9
> DPDK: v21.11

The library hast convert from TSC (cpu clock) to nanoseconds since 1/1/1970=
The function pcapng_init computes the offset.
--000000000000d9b00905e0799358--