Distinguish between "events" and "reports".

Have two different classes of file-type-specific records - "events" and
"reports".  An "event" indicates something that happened in the capture
process, such as a status transition on the network; a "report" just
gives information not corresponding to something happening in the
capture process, such as capture statistics.

Note that both of those should be dissected and displayed like packets,
and leave open the possibility of file-type-specific records whose
contents should be processed and saved but not displayed in the packet
list.

Shorten "file_type_specific" to "ft_specific".

Change-Id: I2342d82ef992c794b76f354c057823dd5eb371e6
Reviewed-on: https://code.wireshark.org/review/1779
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This commit is contained in:
Guy Harris 2014-05-24 14:53:15 -07:00
parent d5b173009c
commit 6dffc3b7e3
2 changed files with 37 additions and 8 deletions

View File

@ -3633,7 +3633,8 @@ static gboolean pcapng_dump(wtap_dumper *wdh,
}
break;
case REC_TYPE_FILE_TYPE_SPECIFIC:
case REC_TYPE_FT_SPECIFIC_EVENT:
case REC_TYPE_FT_SPECIFIC_REPORT:
#ifdef HAVE_PLUGINS
/*
* Do we have a handler for this block type?

View File

@ -889,7 +889,7 @@ struct logcat_phdr {
};
/* Pseudo-header for file-type-specific records */
struct file_type_specific_record_phdr {
struct ft_specific_record_phdr {
guint record_type; /* the type of record this is */
};
@ -919,20 +919,48 @@ union wtap_pseudo_header {
struct nokia_phdr nokia;
struct llcp_phdr llcp;
struct logcat_phdr logcat;
struct file_type_specific_record_phdr ftsrec;
struct ft_specific_record_phdr ftsrec;
};
/*
* Record type values.
*
* This list will expand over time, so don't assume everything will be a
* packet record or a file-type-specific record.
* This list will expand over time, so don't assume everything will
* forever be one of the types listed below.
*
* Non-packet records might have a time stamp; other fields may only
* apply to packet records.
* For file-type-specific records, the "ftsrec" field of the pseudo-header
* contains a file-type-specific subtype value, such as a block type for
* a pcap-ng file.
*
* An "event" is an indication that something happened during the capture
* process, such as a status transition of some sort on the network.
* These should, ideally, have a time stamp and, if they're relevant to
* a particular interface on a multi-interface capture, should also have
* an interface ID. The data for the event is file-type-specific and
* subtype-specific. These should be dissected and displayed just as
* packets are.
*
* A "report" supplies information not corresponding to an event;
* for example, a pcap-ng Interface Statistics Block would be a report,
* as it doesn't correspond to something happening on the network.
* They may have a time stamp, and should be dissected and displayed
* just as packets are.
*
* We distingiush between "events" and "reports" so that, for example,
* the packet display can show the delta between a packet and an event
* but not show the delta between a packet and a report, as the time
* stamp of a report may not correspond to anything interesting on
* the network but the time stamp of an event would.
*
* XXX - are there any file-type-specific records that *shouldn't* be
* dissected and displayed? If so, they should be parsed and the
* information in them stored somewhere, and used somewhere, whether
* it's just used when saving the file in its native format or also
* used to parse *other* file-type-specific records.
*/
#define REC_TYPE_PACKET 0 /**< packet */
#define REC_TYPE_FILE_TYPE_SPECIFIC 1 /**< file-type-specific record */
#define REC_TYPE_FT_SPECIFIC_EVENT 1 /**< file-type-specific event */
#define REC_TYPE_FT_SPECIFIC_REPORT 2 /**< file-type-specific report */
struct wtap_pkthdr {
guint rec_type; /* what type of record is this? */