Oh, that may explain it (from packet-ldap.c) marked with
bold/italic/underline:
*/* check for a SASL header, i.e. assume it is SASL if
* 1, first four bytes (SASL length) is an integer
* with a value that must be <64k and >2
* (>2 to fight false positives, 0x00000000 is a common
* "random" tcp payload)
* (no SASL ldap PDUs are ever going to be >64k in size?)
*
* 2, we must have a conversation and the auth type must
* be LDAP_AUTH_SASL
*/*
sasl_len=tvb_get_ntohl(tvb, 0);
*if*( sasl_len<2 ){
*goto* *this_was_not_sasl*;
}
*if*( sasl_len>*65535* ){
*goto* *this_was_not_sasl*;
}
Apparently, the above assumption is wrong.
Y.
On Thu, Jun 12, 2008 at 11:40 PM, Kaul <[EMAIL PROTECTED]> wrote:
> Wireshark 1.0.0, win32, fails to de-segment (TCP level?) and properly
> dissect a pretty long (229959 bytes entire conversation) SASL wrapped LDAP
> response. Regretfully, I cannot share the capture, but the first packet that
> is not desgemented or dissected in any way (just shows as TCP payload) is
> (partial):
> 0000 00 1a 4a 16 45 5b 00 e0 81 58 df d2 08 00 45 00 ..J.E[...X....E.
> 0010 05 dc 0a 32 40 00 7f 06 b6 5f ac 12 00 0a ac 12 [EMAIL PROTECTED]
> 0020 dd 5b 01 85 04 6f 45 8d a8 34 af 22 1e e4 50 10 .[...oE..4."..P.
> 0030 fc 6b f5 dc 00 00 00 03 6c c9 60 83 03 6c c4 06 .k......l.`..l..
> 0040 09 2a 86 48 86 f7 12 01 02 02 02 01 11 00 ff ff .*.H............
> 0050 ff ff 08 ae f4 9e f4 35 2f ce dc d3 82 f1 55 e9 .......5/.....U.
> 0060 31 69 c4 2b 93 b2 85 fc 80 14 30 84 00 03 6c 7c 1i.+......0...l|
> 0070 02 01 31 64 84 00 03 6c 73 04 40 43 4e 3d 41 67 [EMAIL PROTECTED]
> 0080 67 72 65 67 61 74 65 2c 43 4e 3d 53 63 68 65 6d gregate,CN=Schem
> ...
> Notice from offeset 0x36 (after the TCP header) - the size of the SASL
> buffer is 00 03 6c c9 (224457 bytes), then the usual LDAP ASN.1: 0x60, then
> 0x83, (3 bytes of length which is now 0x36cc4 -> correctly 5 bytes less than
> the SASL buffer, followed by the Kerberos 5 OID, and so on.
> Please note that previos LDAP request and responses were nicely dissected.
> It's just this long response that doesn't play nice. The unbind request at
> the end of all this also looks nice.
>
> I'd be happy to work with someone on testing a fix for it. I could test a
> Windows binary or a source patch in Linux.
>
> Thanks in advance,
> Yaniv.
>
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
