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

diff --git a/pcap-common.h b/pcap-common.h
index cc944ef6..d765c947 100644
--- a/pcap-common.h
+++ b/pcap-common.h
@@ -21,36 +21,8 @@
  * pcap-common.h - common code for pcap and pcapng 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.
- *
- * 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 int dlt_to_linktype(int dlt);
 
 extern int linktype_to_dlt(int linktype);
 
-extern void swap_pseudo_headers(int linktype, struct pcap_pkthdr *hdr,
-    u_char *data);
-
-extern void fixup_pcap_pkthdr(int linktype, struct pcap_pkthdr *hdr,
-    const u_char *data);
-
 extern u_int max_snaplen_for_dlt(int dlt);