Please find attached patch against SVN 25526 to fix the problem. My >64K
capture is working fine with it. The fix:
1. Defines LDAP_SASL_MAX_BUF to 4*64*1024 - in packet-ldap.h
2. Uses it - in packet-ldap.c instead of the hard-coded 65535 value below.
3. Documents this in the comments.
It's obvious
SVN 25443 - same behavior.
On Thu, Jun 12, 2008 at 11:49 PM, Jaap Keuter <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Can you test the last buildbot build? You can find it here:
> http://www.wireshark.org/download/automated/win32/
>
> Thanx,
> Jaap
>
> Kaul wrote:
> > Wireshark 1.0.0, win32, fails to de-
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, 0x00
Hi,
Can you test the last buildbot build? You can find it here:
http://www.wireshark.org/download/automated/win32/
Thanx,
Jaap
Kaul 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 res
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
(pa
