ofp-util: Consistently treat OpenFlow xids as network byte order.

The 'xid' in an ofp_header is not interpreted by the receiver but only by
the sender, so it need not be in any particular byte order.  OVS used to
try to take advantage of this to avoid host/network byte order conversions
for this field.  Older code in OVS, therefore, treats xid as being in host
byte order.  However, as time went on, I forgot that I had introduced this
trick, and so newer code treats xid as being in network byte order.

This commit fixes up the situation by consistently treating xid as being
in network byte order.  I think that this will be less surprising and
easier to remember in the future.

This doesn't fix any actual bugs except that some log messages would have
printed xids in the wrong byte order.

1 files changed, 2 insertions, 1 deletions

diff --git a/lib/vconn.c b/lib/vconn.c
index d2a3829f3..380e374aa 100644
--- a/lib/vconn.c
+++ b/lib/vconn.c
@@ -667,7 +667,8 @@ vconn_recv_xid(struct vconn *vconn, uint32_t xid, struct ofpbuf **replyp)
         }
 
         VLOG_DBG_RL(&bad_ofmsg_rl, "%s: received reply with xid %08"PRIx32
-                    " != expected %08"PRIx32, vconn->name, recv_xid, xid);
+                    " != expected %08"PRIx32,
+                    vconn->name, ntohl(recv_xid), ntohl(xid));
         ofpbuf_delete(reply);
     }
 }