[pcap-ng-format] Proposing new block type for PCAP-NG (UNCLASSIFIED)
Guy Harris
guy at alum.mit.edu
Thu Apr 2 01:05:38 UTC 2015
On Apr 1, 2015, at 12:55 PM, "Renard, Kenneth D CIV USARMY ARL (US)" <kenneth.d.renard.civ at mail.mil> wrote:
>> 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?
>
> I assume this means merge them into the same section?
If you have two captures with one section, the result of merging them would have one section.
> Should there be a way to tie a location provider to an interface identifier?
> Maybe as an option?
Yes, as per my subsequent mail.
> I would hope that per-packet location information would only be used on
> low-rate captures.
I'm not sure that would necessarily be the case for, say, Wi-Fi captures.
> Here is a draft of how these blocks might look. This is intended as a
> reference for discussion and still needs work. Apologize for any line-wrap
> issues.
>
> -Ken
> =====================================================
>
> Two New Block Types
>
> 1. Location Provider Block [Optional]
As per below, perhaps this should be "Location/Orientation Provider Block".
> o Source Types are an enumerated type with a defined list such as:
>
> 0 Undefined source
> 1 GPS
> 2 3GPP
> 3 INS
> [...]
What is "3GPP" as a source type?
Does "GPS" mean "some global navigation satellite system", in which case it should probably be called "GNSS", or does it specifically mean "the US Global Positioning System", in which case we also would want type values for GLONASS, Galileo, BeiDou, IRNSS, and any others I haven't mentioned because they're not listed in
https://en.wikipedia.org/wiki/Template:Geodesy
What is "INS"?
> Option Name Code Length Description Example
>
> lp_device 2 variable A UTF-8 string containing "Garmin 430"
> a description of the
> measuring device.
>
> lp_origin 3 variable A UTF-8 string representing "Earth Center",
> a reference to an origin or
> some specific lat/lon/alt
> for XYX location information
That was a bit strangely formatted, due to odd line wrapping; is the above the intended formatting?
If so, I might be tempted to have separate options for a UTF-8 descriptive string, presumably intended for human consumption, and an actual 3D coordinate value, for computer consumption.
> lp_name 4 variable A UTF-8 string containing "Vehicle X",
> a description of the
> location provider.
Perhaps it should be called "lp_description"?
> lp_error_type 5 32-bit An enumeration of the type NUMBER_OF_SATELLITES,
> unsigned int of error described in location CONFIDENCE_PERCENTAGE,
> information blocks that ACCURACY_IN_METERS
> reference this location
> provider.
Presumably "error" means "possible source of inaccuracy in the measurement" rather than "reason why a measurement couldn't be made", i.e. "error" in the sense of "error bar" rather than "error code".
Perhaps, instead of one lb_error option, there should be separate options for different types of accuracy/confidence, each specifying the (possibly-binary) format of the indication.
> 2. Location Block
>
> The Location Block provides some idea of where the capture is taking place.
> This could be a descriptive location such as "DMZ", "Server Room", or
> "Starbucks". It could also be a geographic location specified in some
> format.
> Examples of specific formats for geographic location are: "Lattitude-
> Longitude-Altitude", "Orientation" (pitch, yaw, roll),
The orientation isn't really a location, so perhaps this should be called the "Location/Orientation Block" or something such as that.
> Option Name Code Length Description Example
>
> lb_lla 2 12 bytes Three 32-bit signed integers 32786026, -96801908, 42
> representing the Latitude, represents 32.786026 degrees
> Longitude, and altitude of latitude, -96.801908 degrees
> the location. Latitude and longitude, and 42 meters
> Longitude are expressed as above MSL
> millionths of degrees
> (10^-6 degrees) and altitude
> is expressed as meters above
> mean sea level (MSL)
https://en.wikipedia.org/wiki/World_Geodetic_System
says
Currently, WGS 84 uses the EGM96 (Earth Gravitational Model 1996) geoid, revised in 2004. This geoid defines the nominal sea level surface by means of a spherical harmonics series of degree 360 (which provides about 100 km horizontal resolution).
Is "mean sea level" here something defined by a particular specified standard, in which case the proposal should indicate what standard that is, or is the particular standard being used something that can be chosen, in which case the Location Provider Block should probably indicate what standard is being used.
> lb_orientation 3 12 bytes Three 32-bit signed integers 45000000,115000000,-500000
> representing the pitch, yaw, represents 45.0 degrees pitch,
> and roll angles expressed in 114.0 degrees roll, and -0.5
> millionths of degrees degrees yaw.
> (10^-6 degrees). The
> reference plane for these
> measurements should be a
> tangent to the base surface,
> or the Z=0 (altitude=0)
> surface
So is the point of tangency the point whose latitude and longitude or X and Y coordinates are given as the location and whose altitude or Z coordinate is 0?
>
> lb_xyz 4 12 bytes Three 32-bit signed integers 42, -166, 0 represents 42 meters
> representing the distance from from x=0 axis, -166 meters from
> the X, Y, and Z axis in meters. y=0 axis, and 0 meters from the
> A reference to the origin point z=0 axis.
> may be found in the location
> provider block.
>
> lb_description 5 variable A UTF-8 string containing "Server Room", "DMZ"
> a description of the location.
> Interpretation of this field
> is up to the applications that
> generates and use this field
...or the human who reads it, i.e. the application may only display it to the user.
> lb_hiprexyz 6 28 bytes A high-precision offset along 3, 42, -166, 0 represents
> the X, Y, and Z axis. It is a distance of 42km from the
> made up of a 32-bit signed x=0 axis, -166km from the
> value that represents a y=0 axis, and 0km from the
> resolution, followed by three z=0 axis
> 64-bit signed values
> representing the distance in
> the X, Y, and Z directions
> respectively. The resolution
> is a signed integer that
> specifies the power of 10 for
> the units of the X, Y, and Z
> values in meters. If the
> resolution value is -6, then
> the X, Y, and Z offsets are in
> micrometers from the origin.
> It the resolution value is 3,
> the X, Y, and Z offsets are in
> kilometers from the origin. A
> eeference to the origin point
> may be found in the location
> provider block.
Presumably "A *reference* to the origin point..."
Is the resolution likely to change from measurement to measurement, or should it be given in the Location Provider Block?
> lb_error 7 variable A UTF-8 string containing
> some indication of the error
> tolerance expected from this
> location measurement.
> Interpretation of this field
> is dependent on the lp_error_type
> defined in the location provider
> block.
As noted above, perhaps it should be specified by the option type.
More information about the pcap-ng-format
mailing list