Well, perhaps that padding really *is* padding, or maybe it's some other

gunk stuck in there to make NTLMSSP happy (perhaps the encrypted body
length has to be a multiple of 16 bytes or something such as that for
the encryption to work).

No packet in any capture I have appears to be misdissected if you get
rid of the mod 4 stuff, so I'm removing it.

svn path=/trunk/; revision=7181

diff --git a/packet-dcerpc.c b/packet-dcerpc.c
index 04b4c9b3df51d790990db7953845adbb61c47376..31b0d938a5cf7391bb9f768e0e9ad5baa5da7ba5 100644 (file)
--- a/packet-dcerpc.c
+++ b/packet-dcerpc.c
@@ -2,7 +2,7 @@
  * Routines for DCERPC packet disassembly
  * Copyright 2001, Todd Sabin <tas@webspan.net>
  *
- * $Id: packet-dcerpc.c,v 1.108 2003/02/11 02:18:27 guy Exp $
+ * $Id: packet-dcerpc.c,v 1.109 2003/02/21 04:31:38 guy Exp $
  *
  * Ethereal - Network traffic analyzer
  * By Gerald Combs <gerald@ethereal.com>
@@ -1855,17 +1855,6 @@ dissect_dcerpc_cn_auth (tvbuff_t *tvb, packet_info *pinfo, proto_tree *dcerpc_tr
            }
        }
 
-       /*
-        * XXX - sometimes the padding is a multiple of 4 and greater
-        * than 3, meaning it's not padding to put the authentication
-        * data on a 4-byte boundary.
-        *
-        * For now, we take its value mod 4.
-        *
-        * XXX - what is going on there?
-        */
-       auth_info->auth_pad_len %= 4;
-
         /* figure out where the auth padding starts */
         offset = hdr->frag_len - (hdr->auth_len + 8 + auth_info->auth_pad_len);
         if (offset > 0 && auth_info->auth_pad_len) {