Add comments explaining why using EXTRACT_BE_U_4() isn't wrong.

When showing a readdir verifier, using big-endian means that it shows
the verifier as a string of 16 octet values, from the first to the last,
which makes sense, and which means that the way we display it is
independent of the byte order of the host running tcpdump, which is a
Good Thing.

When showing a file handle, the same applies, although one could make a
case for not separating the 4-octet words with colons, and just showing
it as a sequence of octets.

diff --git a/print-nfs.c b/print-nfs.c
index 04c98becb29becb051a54e8dd63c2b0af5ae23c6..c4bda5232a7819aefc208bb5402090ded5203da4 100644 (file)
--- a/print-nfs.c
+++ b/print-nfs.c
@@ -716,10 +716,17 @@ nfsreq_noaddr_print(netdissect_options *ndo,
                                ND_PRINT((ndo, " %u bytes @ %" PRId64,
                                    EXTRACT_BE_U_4(dp + 4),
                                    EXTRACT_BE_U_8(dp)));
-                               if (ndo->ndo_vflag)
+                               if (ndo->ndo_vflag) {
+                                       /*
+                                        * This displays the 8 bytes
+                                        * of the verifier in order,
+                                        * from the low-order byte
+                                        * to the high-order byte.
+                                        */
                                        ND_PRINT((ndo, " verf %08x%08x",
                                                  EXTRACT_BE_U_4(dp + 2),
                                                  EXTRACT_BE_U_4(dp + 3)));
+                               }
                        } else {
                                ND_TCHECK(dp[1]);
                                /*
@@ -747,6 +754,12 @@ nfsreq_noaddr_print(netdissect_options *ndo,
                                EXTRACT_BE_U_8(dp)));
                        if (ndo->ndo_vflag) {
                                ND_TCHECK(dp[5]);
+                               /*
+                                * This displays the 8 bytes
+                                * of the verifier in order,
+                                * from the low-order byte
+                                * to the high-order byte.
+                                */
                                ND_PRINT((ndo, " max %u verf %08x%08x",
                                          EXTRACT_BE_U_4(dp + 5),
                                          EXTRACT_BE_U_4(dp + 2),
@@ -800,6 +813,18 @@ nfs_printfh(netdissect_options *ndo,
 
                ND_PRINT((ndo, " fh["));
                for (i=0; i<len; i++) {
+                       /*
+                        * This displays 4 bytes in big-endian byte
+                        * order.  That's as good a choice as little-
+                        * endian, as there's no guarantee that the
+                        * server is big-endian or little-endian or
+                        * that the file handle contains 4-byte
+                        * integral fields, and is better than "the
+                        * byte order of the host running tcpdump", as
+                        * the latter means that different hosts
+                        * running tcpdump may show the same file
+                        * handle in different ways.
+                        */
                        ND_PRINT((ndo, "%s%x", sep, EXTRACT_BE_U_4(dp + i)));
                        sep = ":";
                }
@@ -1370,6 +1395,10 @@ parsev3rddirres(netdissect_options *ndo,
                return dp;
        if (ndo->ndo_vflag) {
                ND_TCHECK(dp[1]);
+               /*
+                * This displays the 8 bytes of the verifier in order,
+                * from the low-order byte to the high-order byte.
+                */
                ND_PRINT((ndo, " verf %08x%08x",
                          EXTRACT_BE_U_4(dp), EXTRACT_BE_U_4(dp + 1)));
                dp += 2;