rpcap: have the server tell the client its byte order.

Stick a byte-order magic number, in the host byte order of the server,
into the authentication reply.

If the authentication reply is large enough to contain that magic
number, extract it and, from it, determine whether the server's byte
order is the opposite of the client's byte order; if it's not present,
assume the server has the same byte order.

If the two byte orders are differen, do the same byte-order fixing of
the packet contents that we do when reading a pcap file or pcapng
section with the opposite byte order, so that host-byte-order fields are
converted from the byte order of the host that sent or wrote them to the
byte order of the host that received or read them.

This change will allow a client to work with all servers, regardless of
whether they provide the byte order or not, although if the server
doesn't provide the byte order, and it happens to be the opposite of the
client's byte order, packets with a link-layer header type that contains
host-byte-order fields will not be able to be processed correctly.  It
also allows clients that don't handle the byte order magic number in the
authentication reply to work with all servers, as they will just discard
what they consider extra data at the end of the reply.

(Note: fixing the byte order in the server requires that the client send
a byte order indication to the server, so *either* fix works only
between an updated client and an updated server.  We already have
optional data in the authentication reply, to allow updated servers and
clients to negotiate a protocol version while still allowing updated
clients to work with older servers and older clients to work with
updated servers, so this just continues that mechanism.)

1 files changed, 55 insertions, 0 deletions

diff --git a/pcap-util.h b/pcap-util.h
new file mode 100644
index 00000000..de958191
--- /dev/null
+++ b/pcap-util.h
@@ -0,0 +1,55 @@
+/*
+ * Copyright (c) 1993, 1994, 1995, 1996, 1997
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that: (1) source code distributions
+ * retain the above copyright notice and this paragraph in its entirety, (2)
+ * distributions including binary code include the above copyright notice and
+ * this paragraph in its entirety in the documentation or other materials
+ * provided with the distribution, and (3) all advertising materials mentioning
+ * features or use of this software display the following acknowledgement:
+ * ``This product includes software developed by the University of California,
+ * Lawrence Berkeley Laboratory and its contributors.'' Neither the name of
+ * the University nor the names of its contributors may be used to endorse
+ * or promote products derived from this software without specific prior
+ * written permission.
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ * pcap-util.h - common code for various files
+ */
+
+/*
+ * We use the "receiver-makes-right" approach to byte order;
+ * because time is at a premium when we are writing the file.
+ * In other words, the pcap_file_header and pcap_pkthdr,
+ * records are written in host byte order.
+ * Note that the bytes of packet data are written out in the order in
+ * which they were received, so multi-byte fields in packets are not
+ * written in host byte order, they're written in whatever order the
+ * sending machine put them in.
+ *
+ * We also use this for fixing up packet data headers from a remote
+ * capture, where the server may have a different byte order from the
+ * client.
+ *
+ * ntoh[ls] aren't sufficient because we might need to swap on a big-endian
+ * machine (if the file was written in little-end order).
+ */
+#define	SWAPLONG(y) \
+    (((((u_int)(y))&0xff)<<24) | \
+     ((((u_int)(y))&0xff00)<<8) | \
+     ((((u_int)(y))&0xff0000)>>8) | \
+     ((((u_int)(y))>>24)&0xff))
+#define	SWAPSHORT(y) \
+     ((u_short)(((((u_int)(y))&0xff)<<8) | \
+                ((((u_int)(y))&0xff00)>>8)))
+
+extern void pcap_post_process(int linktype, int swapped,
+    struct pcap_pkthdr *hdr, u_char *data);
+
+extern void fixup_pcap_pkthdr(int linktype, struct pcap_pkthdr *hdr,
+    const u_char *data);
+