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

[Hadriel Kaplan]

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. 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.

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.

If the start/end times don't line up nicely like that in one of those
two ways, then I think all bets are off. A reading app can ignore them
completely, or keep/show them all, or whatever - though I think we
should say it MUST gracefully handle it without generating a file
reading error. (i.e., warnings are ok, but don't consider the file
malformed)


In terms of what pcapng files do right now:

The only apps I know of that generate an ISB right now are
Wireshark/tshark/dumpcap, all due to dumpcap generating it.  And as
you undoubtedly know, dumpcap only generates one per interface, at the
end of the file, for the whole capture time.

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. Thus if you only open up one of the earlier files,
you'll not see any stats; if you open up the last one, you'll see
stats that don't actually apply to just that file alone.

In terms of reading a pcapng, Wireshark currently only displays the
ISB statistics if there was one, and only one, ISB per interface. (and
right now it only shows the 'isb_ifdrop' count)

-hadriel
[1] as an aside, it's too bad the SHB doesn't have a timestamp of when
it was created - it would be useful to know when the SHB section was
created, and it would have been useful in this case as well.