aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorGuy Harris <guy@alum.mit.edu>2017-11-18 10:36:54 -0800
committerGuy Harris <guy@alum.mit.edu>2017-11-18 18:37:34 +0000
commitadc1aff0a54bb54d313ea82cfeb3cb928d8f1974 (patch)
treeb4db326a27faf7eb20eea0a8ff992293d1650960
parentc42878bea8ea41954d3bae75ab749ac7881201c9 (diff)
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>
-rw-r--r--epan/dissectors/packet-pktap.c26
1 files changed, 18 insertions, 8 deletions
diff --git a/epan/dissectors/packet-pktap.c b/epan/dissectors/packet-pktap.c
index 195115c..8795b46 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