summaryrefslogtreecommitdiff
path: root/tshark.c
diff options
context:
space:
mode:
authorGuy Harris <guy@alum.mit.edu>2017-04-12 13:52:07 -0700
committerGuy Harris <guy@alum.mit.edu>2017-04-12 23:33:37 +0000
commit847c25c5a7e7c5653870c4bd60625da1c64c86f1 (patch)
tree386b51025493bda76c077334293d931eded5afdf /tshark.c
parent74f9b279e9888b0449b569a1c474351ccc991d5e (diff)
downloadwireshark-847c25c5a7e7c5653870c4bd60625da1c64c86f1.tar.gz
Prime the epan_dissect_t with postdissector wanted fields if necessary.
This makes sure that postdissectors that indicate that they need certain fields in the first pass will get them. While we're at it: Fix the field-fetching code in TRANSUM not to assume it got any instances of the field being fetched. Rename process_packet_first_pass() in sharkd to process_packet(), as it's the only routine in sharkd that processes packets. Rename process_packet() in tshark and tfshark to process_packet_single_pass(), as it's what's used if we're only doing one-pass analysis. Clean up comments and whitespace. Change-Id: I3769af952c66f5ca4b68002ad6213858ab9cab9b Reviewed-on: https://code.wireshark.org/review/21063 Reviewed-by: Guy Harris <guy@alum.mit.edu>
Diffstat (limited to 'tshark.c')
-rw-r--r--tshark.c123
1 files changed, 54 insertions, 69 deletions
diff --git a/tshark.c b/tshark.c
index 458b08fa35..a05f4a698b 100644
--- a/tshark.c
+++ b/tshark.c
@@ -228,9 +228,9 @@ static char *output_file_name;
#endif /* HAVE_LIBPCAP */
static int load_cap_file(capture_file *, char *, int, gboolean, int, gint64);
-static gboolean process_packet(capture_file *cf, epan_dissect_t *edt, gint64 offset,
- struct wtap_pkthdr *whdr, const guchar *pd,
- guint tap_flags);
+static gboolean process_packet_single_pass(capture_file *cf,
+ epan_dissect_t *edt, gint64 offset, struct wtap_pkthdr *whdr,
+ const guchar *pd, guint tap_flags);
static void show_capture_file_io_error(const char *, int, gboolean);
static void show_print_file_io_error(int err);
static gboolean write_preamble(capture_file *cf);
@@ -1166,18 +1166,29 @@ main(int argc, char *argv[])
goto clean_exit;
break;
case 'l': /* "Line-buffer" standard output */
- /* This isn't line-buffering, strictly speaking, it's just
- flushing the standard output after the information for
- each packet is printed; however, that should be good
- enough for all the purposes to which "-l" is put (and
- is probably actually better for "-V", as it does fewer
- writes).
-
- See the comment in "process_packet()" for an explanation of
- why we do that, and why we don't just use "setvbuf()" to
- make the standard output line-buffered (short version: in
- Windows, "line-buffered" is the same as "fully-buffered",
- and the output buffer is only flushed when it fills up). */
+ /* The ANSI C standard does not appear to *require* that a line-buffered
+ stream be flushed to the host environment whenever a newline is
+ written, it just says that, on such a stream, characters "are
+ intended to be transmitted to or from the host environment as a
+ block when a new-line character is encountered".
+
+ The Visual C++ 6.0 C implementation doesn't do what is intended;
+ even if you set a stream to be line-buffered, it still doesn't
+ flush the buffer at the end of every line.
+
+ The whole reason for the "-l" flag in either tcpdump or TShark
+ is to allow the output of a live capture to be piped to a program
+ or script and to have that script see the information for the
+ packet as soon as it's printed, rather than having to wait until
+ a standard I/O buffer fills up.
+
+ So, if the "-l" flag is specified, we flush the standard output
+ at the end of a packet. This will do the right thing if we're
+ printing packet summary lines, and, as we print the entire protocol
+ tree for a single packet without waiting for anything to happen,
+ it should be as good as line-buffered mode if we're printing
+ protocol trees - arguably even better, as it may do fewer
+ writes. */
line_buffered = TRUE;
break;
case 'L': /* Print list of link-layer types and exit */
@@ -2600,9 +2611,9 @@ capture_input_new_packets(capture_session *cap_session, int to_read)
wtap_close(cf->wth);
cf->wth = NULL;
} else {
- ret = process_packet(cf, edt, data_offset, wtap_phdr(cf->wth),
- wtap_buf_ptr(cf->wth),
- tap_flags);
+ ret = process_packet_single_pass(cf, edt, data_offset,
+ wtap_phdr(cf->wth),
+ wtap_buf_ptr(cf->wth), tap_flags);
}
if (ret != FALSE) {
/* packet successfully read and gone through the "Read Filter" */
@@ -2773,8 +2784,8 @@ capture_cleanup(int signum _U_)
static gboolean
process_packet_first_pass(capture_file *cf, epan_dissect_t *edt,
- gint64 offset, struct wtap_pkthdr *whdr,
- const guchar *pd)
+ gint64 offset, struct wtap_pkthdr *whdr,
+ const guchar *pd)
{
frame_data fdlocal;
guint32 framenum;
@@ -2810,6 +2821,10 @@ process_packet_first_pass(capture_file *cf, epan_dissect_t *edt,
if (cf->dfcode)
epan_dissect_prime_with_dfilter(edt, cf->dfcode);
+ /* This is the first pass, so prime the epan_dissect_t with the
+ fields postdissectors want on the first pass. */
+ prime_epan_dissect_with_postdissector_wanted_fields(edt);
+
frame_data_set_before_dissect(&fdlocal, &cf->elapsed_time,
&ref, prev_dis);
if (ref == &fdlocal) {
@@ -2854,9 +2869,9 @@ process_packet_first_pass(capture_file *cf, epan_dissect_t *edt,
}
static gboolean
-process_packet_second_pass(capture_file *cf, epan_dissect_t *edt, frame_data *fdata,
- struct wtap_pkthdr *phdr, Buffer *buf,
- guint tap_flags)
+process_packet_second_pass(capture_file *cf, epan_dissect_t *edt,
+ frame_data *fdata, struct wtap_pkthdr *phdr,
+ Buffer *buf, guint tap_flags)
{
column_info *cinfo;
gboolean passed;
@@ -2917,26 +2932,9 @@ process_packet_second_pass(capture_file *cf, epan_dissect_t *edt, frame_data *fd
this packet. */
print_packet(cf, edt);
- /* The ANSI C standard does not appear to *require* that a line-buffered
- stream be flushed to the host environment whenever a newline is
- written, it just says that, on such a stream, characters "are
- intended to be transmitted to or from the host environment as a
- block when a new-line character is encountered".
-
- The Visual C++ 6.0 C implementation doesn't do what is intended;
- even if you set a stream to be line-buffered, it still doesn't
- flush the buffer at the end of every line.
-
- So, if the "-l" flag was specified, we flush the standard output
- at the end of a packet. This will do the right thing if we're
- printing packet summary lines, and, as we print the entire protocol
- tree for a single packet without waiting for anything to happen,
- it should be as good as line-buffered mode if we're printing
- protocol trees. (The whole reason for the "-l" flag in either
- tcpdump or TShark is to allow the output of a live capture to
- be piped to a program or script and to have that script see the
- information for the packet as soon as it's printed, rather than
- having to wait until a standard I/O buffer fills up. */
+ /* If we're doing "line-buffering", flush the standard output
+ after every packet. See the comment above, for the "-l"
+ option, for an explanation of why we do that. */
if (line_buffered)
fflush(stdout);
@@ -3121,7 +3119,7 @@ load_cap_file(capture_file *cf, char *save_file, int out_file_type,
tshark_debug("tshark: reading records for first pass");
while (wtap_read(cf->wth, &err, &err_info, &data_offset)) {
if (process_packet_first_pass(cf, edt, data_offset, wtap_phdr(cf->wth),
- wtap_buf_ptr(cf->wth))) {
+ wtap_buf_ptr(cf->wth))) {
/* Stop reading if we have the maximum number of packets;
* When the -c option has not been used, max_packet_count
* starts at 0, which practically means, never stop reading.
@@ -3332,9 +3330,8 @@ load_cap_file(capture_file *cf, char *save_file, int out_file_type,
tshark_debug("tshark: processing packet #%d", framenum);
- if (process_packet(cf, edt, data_offset, wtap_phdr(cf->wth),
- wtap_buf_ptr(cf->wth),
- tap_flags)) {
+ if (process_packet_single_pass(cf, edt, data_offset, wtap_phdr(cf->wth),
+ wtap_buf_ptr(cf->wth), tap_flags)) {
/* Either there's no read filtering or this packet passed the
filter, so, if we're writing to a capture file, write
this packet out. */
@@ -3524,8 +3521,9 @@ out:
}
static gboolean
-process_packet(capture_file *cf, epan_dissect_t *edt, gint64 offset, struct wtap_pkthdr *whdr,
- const guchar *pd, guint tap_flags)
+process_packet_single_pass(capture_file *cf, epan_dissect_t *edt, gint64 offset,
+ struct wtap_pkthdr *whdr, const guchar *pd,
+ guint tap_flags)
{
frame_data fdata;
column_info *cinfo;
@@ -3557,6 +3555,10 @@ process_packet(capture_file *cf, epan_dissect_t *edt, gint64 offset, struct wtap
if (cf->dfcode)
epan_dissect_prime_with_dfilter(edt, cf->dfcode);
+ /* This is the first and only pass, so prime the epan_dissect_t
+ with the fields postdissectors want on the first pass. */
+ prime_epan_dissect_with_postdissector_wanted_fields(edt);
+
col_custom_prime_edt(edt, &cf->cinfo);
/* We only need the columns if either
@@ -3594,26 +3596,9 @@ process_packet(capture_file *cf, epan_dissect_t *edt, gint64 offset, struct wtap
this packet. */
print_packet(cf, edt);
- /* The ANSI C standard does not appear to *require* that a line-buffered
- stream be flushed to the host environment whenever a newline is
- written, it just says that, on such a stream, characters "are
- intended to be transmitted to or from the host environment as a
- block when a new-line character is encountered".
-
- The Visual C++ 6.0 C implementation doesn't do what is intended;
- even if you set a stream to be line-buffered, it still doesn't
- flush the buffer at the end of every line.
-
- So, if the "-l" flag was specified, we flush the standard output
- at the end of a packet. This will do the right thing if we're
- printing packet summary lines, and, as we print the entire protocol
- tree for a single packet without waiting for anything to happen,
- it should be as good as line-buffered mode if we're printing
- protocol trees. (The whole reason for the "-l" flag in either
- tcpdump or TShark is to allow the output of a live capture to
- be piped to a program or script and to have that script see the
- information for the packet as soon as it's printed, rather than
- having to wait until a standard I/O buffer fills up. */
+ /* If we're doing "line-buffering", flush the standard output
+ after every packet. See the comment above, for the "-l"
+ option, for an explanation of why we do that. */
if (line_buffered)
fflush(stdout);