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, 19 insertions, 0 deletions

diff --git a/rpcap-protocol.h b/rpcap-protocol.h
index 7f6574c1..ffb401d3 100644
--- a/rpcap-protocol.h
+++ b/rpcap-protocol.h
@@ -152,6 +152,25 @@ struct rpcap_header
  */
 struct rpcap_authreply
 {
+	uint8_t minvers;		/* Minimum version supported */
+	uint8_t maxvers;		/* Maximum version supported */
+	uint8_t pad[2];			/* Pad to 4-byte boundary **/
+	uint32_t byte_order_magic;	/* RPCAP_BYTE_ORDER_MAGIC, in server byte order */
+};
+
+/*
+ * Any resemblance between this and the pcap file magic number
+ * is purely coincidental, trust me.
+ */
+#define RPCAP_BYTE_ORDER_MAGIC		0xa1b2c3d4U
+#define RPCAP_BYTE_ORDER_MAGIC_SWAPPED	0xd4c3b2a1U
+
+/*
+ * Older version of authentication reply, without byte order indication
+ * and padding.
+ */
+struct rpcap_authreply_old
+{
 	uint8_t minvers;	/* Minimum version supported */
 	uint8_t maxvers;	/* Maximum version supported */
 };