Don't do pcap heuristics on a pipe.

Instead, just:

  assume a file with the regular pcap magic number is a regular pcap
  file, not an unhelpfully-modified-without-changing-the-magic-number
  format such as one of the (fortunately, short-lived) memory-mapped
  capture formats or the Nokia format;

  reject a file with the memory-mapped-capture-finally-changed-the-
  magic-number magic number, as they then changed the *new* format
  without changing its magic number;

  and don't even leave a provision for multiple formats using the
  "nanosecond pcap" magic number - not even when reading from a file -
  so we can punish bad behavior (which is what changing the format
  without changing the magic number is).

This should get rid of the last place where, when reading a pcap file
from a pipe, the first packet isn't displayed as soon as it arrives.

Bug: 14345
Change-Id: I2fcb3354dc84cdd2d8ec749a0db883e56971c4b4
Reviewed-on: https://code.wireshark.org/review/25383
Reviewed-by: Guy Harris <guy@alum.mit.edu>

1 files changed, 1 insertions, 0 deletions

diff --git a/wiretap/wtap-int.h b/wiretap/wtap-int.h
index 01d697b7ac..4dc22ebeb9 100644
--- a/wiretap/wtap-int.h
+++ b/wiretap/wtap-int.h
@@ -47,6 +47,7 @@ typedef gboolean (*subtype_seek_read_func)(struct wtap*, gint64,
 struct wtap {
     FILE_T                      fh;
     FILE_T                      random_fh;              /**< Secondary FILE_T for random access */
+    gboolean                    ispipe;                 /**< TRUE if the file is a pipe */
     int                         file_type_subtype;
     guint                       snapshot_length;
     struct Buffer               *frame_buffer;