[pcap-ng-format] Proposing new block type for PCAP-NG (UNCLASSIFIED)

[Guy Harris]

On Mar 30, 2015, at 6:32 AM, "Renard, Kenneth D CIV USARMY ARL (US)" <kenneth.d.renard.civ at mail.mil> wrote:

> I think this is worthy of discussion.  It would be a waste to require (or infer that it is required) to generate a position block for each interface at each chosen interval.  If I had N interfaces and chose to report positions every second, that could get wasteful.
> 
> What do you think of a position report that references interface -1 (0xffffffff) which specifies "all interfaces" but would still need some timestamp resolution reference (default to microseconds?).

Wireshark, at least, allows multiple capture files to be merged into a single capture file.  What happens if you take two captures, perhaps from two different machines in different positions traveling over different paths, taken over the same time period, and merge them?

Perhaps, instead, we could treat position providers similarly to interfaces, and have a "location provider information block" that gives information such as time resolution - and perhaps other information, such as source (GPS, GLONASS, Galileo, etc.), resolution, etc.?  A Location Information Block would have, instead of an interface ID, a "location provider" ID, which would be the ordinal number of the "location provider information block" within the section.

A machine could have multiple location providers, including one per interface, so that'd support both "my mobile computer with its GPS, Wi-Fi, and mobile phone interface" and "my machine, gathering packets from multiple probes moving independently".

Merging captures would mean assigning a new set of location provider IDs and updating LIBs to use the new IDs.

If we went for per-packet location information, the option to give a location report with a packet would include both a location provider ID and location information.

I suppose if we're concerned about the additional 2 to 4 bytes of location provider ID in position reports, we could have "simple" versions of the LIB and location options, with the location provider being implied to be the first one.  When merging, "simple" versions might be turned into the non-simple ones as necessary.

> Agreed.  Frequency of location information is defined by the
> application/user.
> Example use cases might be:
> 
>  1.  Set location description each time I wake up my laptop
>  2.  Synchronous stream from GPS:  Once per second, per interface.
>  3.  Every N seconds or change in position more than M meters.
> 
> Location information per-packet seems extreme, but certainly valid.

Well, it's an option, so it's not as if *every* packet has to have it; it could be attached as an option to a packet if the position is "significantly" different from the one for the previous packet.