The header is host-endian, not little-endian. Note that.

Change-Id: I7fc2874026430c3d7e8633c48ee0558ad69d5c9a
Reviewed-on: https://code.wireshark.org/review/24480
Reviewed-by: Guy Harris <guy@alum.mit.edu>

1 files changed, 18 insertions, 8 deletions

diff --git a/epan/dissectors/packet-pktap.c b/epan/dissectors/packet-pktap.c
index 195115cb0e..8795b46a42 100644
--- a/epan/dissectors/packet-pktap.c
+++ b/epan/dissectors/packet-pktap.c
@@ -81,15 +81,25 @@ static dissector_handle_t pktap_handle;
 static capture_dissector_handle_t eth_cap_handle;
 
 /*
- * XXX - these are little-endian in the captures I've seen, but Apple
- * no longer make any big-endian machines (Macs use x86, iOS machines
- * use ARM and run it little-endian), so that might be by definition
- * or they might be host-endian.
+ * XXX - these are only little-endian because they've been created on
+ * little-endian machines; the code in bsd/net/pktap.c in XNU writes
+ * the structure out in host byte order.
  *
- * If a big-endian PKTAP file ever shows up, and it comes from a
- * big-endian machine, presumably these are host-endian, and we need
- * to just fetch the fields in host byte order here but byte-swap them
- * to host byte order in libwiretap.
+ * We haven't been treating it as host-endian in libpcap and libwiretap,
+ * i.e. we haven't been byte-swapping its members when reading it on
+ * a machine whose byte order differs from the byte order of the machine
+ * on which the file is being read.
+ *
+ * Furthermore, the header is extensible, so we don't necessarily know
+ * what fields to swap.
+ *
+ * Fortunately, the length of the PKTAP header is a 32-bit field and is
+ * *presumably* never going to be 65536 or greater, so if any of the upper
+ * 16 bits appear to be set, it means we're looking at it in the wrong
+ * byte order, and it's never going to be zero, so those bits *will* be
+ * set if it's >= 65536, so we can determine its byte order.
+ *
+ * We should do that here.
  */
 
 static gboolean