[pcap-ng-format] Multiple capture start and end times for an interface?

[Guy Harris]

On Aug 29, 2015, at 7:07 PM, Hadriel Kaplan <the.real.hadriel at gmail.com> wrote:

> On Wed, Aug 26, 2015 at 5:21 PM, Guy Harris <guy at alum.mit.edu> wrote:
>> What does it mean if there are multiple Interface Statistics Blocks with isb_starttime or isb_endtime values? Should the first isb_starttime value seen be treated as the actual start time and the last isb_endtime value seen be treated as the actual end time?
> 
> My 2 cents:
> 
> I think the logical thing would be that the statistics within the ISB
> apply to the time range their start/end time options indicate.

That changes the meaning of the start and end times from "time the capture started and time the capture ended" to "time the interval the statistics cover started and time that interval ended".

> So if
> there are two ISBs for the same interface in an SHB section, and the
> first ISB has a start time of X and end time of Y, and the second ISB
> has a start time of Y and end time of Z, then a reading app would sum
> their statistic counts, to get the whole time range X-Z. If the second
> ISB had instead a start time of X and end time of Z, then the second
> one would be used in place of the first; i.e., it's counts are
> cumulative and win/supersede.

Is the ability to have multiple intervals - which could potentially overlap, and which could potentially not cover the entire capture - useful?  It complicates the processing.

> If an ISB doesn't have a start time, then it should be implicitly
> assumed to be the first EPB's timestamp for that interface; or 0 if
> there is no EPB in the SHB for the same interface.[1]  If an ISB
> doesn't have an end time, then it should be implicitly assumed to be
> the ISB block header's timestamp. The same rules of time ranges apply
> even with these implicit assumptions; for example, if the SHB has two
> ISBs for the same interface, both without start and end time options,
> the second overlaps the first and is cumulative.

I.e., the second supersedes the first.

> In terms of what pcapng files do right now:

	...

> And I believe (from code inspection not trying it) that if a ring-file
> output mode is being used, then it only generates the ISB for each
> interface in the last/final file, but for the whole capture time its
> been running.

Hmm.  I'd call that a dumpcap bug - it should dump out a statistics block when it closes a file, and do what's necessary to reset the counts so that the next ISB it dumps includes only statistics for that file (reset counters that it maintains, remember counters it gets from libpcap and subtract the remembered value from the next value it fetches).