[pcap-ng-format] Proposal for new "custom" option codes

[Guy Harris]

On Jul 22, 2015, at 12:34 PM, Jasper Bongertz <jasper at packet-foo.com> wrote:

> On Wednesday, July 22, 2015, 9:13:49 PM, Guy Harris wrote:
> 
>> And it means that, if you were capturing on interfaces A, B, and C,
>> but didn't happen to see any packets on interface C (because they
>> didn't pass the filter, or whatever), the fact that you were
>> capturing on interface C isn't recorded anywhere in the file.
> 
> You're right, I didn't think of that. And having IDBs at the beginning
> of the file has advantages as they can be read without scanning the
> whole file first.

We don't guarantee that all IDBs will be at the beginning of the file.  Currently, if you capture with the Linux "any" device, there's one IDB for the "any" device, but we really should add IDBs for all known interfaces and, in the best case, add IDBs for interfaces as they arrive (which would involve receiving netlink messages saying "here's a new interface", so capturing would involve select()/poll()/epoll() even if you're capturing on one interface), with "add IDBs for new interfaces as we see packets" being a fallback.

> Which may still be required in some situations where
> the IDBs are spread across the file, of course.

Yes, and there's no way to tell whether IDBs appear later in the file other than looking for them.

>> That might be an argument *against* ordinal IDs and *for* assigning
>> UUIDs *and* using the UUID in the option.
> 
> Ordinal IDs are still useful since it's much more space efficient to
> reference them in the packet blocks.

So for any block type for which ordinal IDs are assigned and option that uses the ordinal ID, we'll need merging plugins in libwireshark and any *other* code that does file merging.