Wireshark-bugs: [Wireshark-bugs] [Bug 8570] New: LDAP dissector doesn't account for reuse of Mes
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Mon, 08 Apr 2013 15:37:47 +0000
Bug ID 8570
Summary LDAP dissector doesn't account for reuse of MessageID - ldap.time HORRIBLY incorrect
Classification Unclassified
Product Wireshark
Version unspecified
Hardware All
OS All
Status UNCONFIRMED
Severity Major
Priority Low
Component Dissection engine (libwireshark)
Assignee bugzilla-admin@wireshark.org
Reporter wesmorgan1@hotmail.com 

Build Information:
Observed in prepackaged Windows install (1.8.0 (SVN Rev 43431 from /trunk-1.8))
and Linux build from 1.8.5 source tarball.
--
The LDAP RFCs state that an LDAP MessageID may be reused, as long as the
previous request has completed.  While it specifies that MessageID may be in
the range [1..MAXINT], it does not mandate that clients use a particular
maximum value before recycling.  So, it is not uncommon to see the same
MessageID appear multiple times in a single LDAP conversation.  I have seen
clients that don't recycle at all (i.e. they seem to use the full range),
clients that recycle after reaching a MessageID of 1023, and even a client that
recycles after reaching 511.

So, it is not uncommon to see a MessageID "flow" like this:

searchRequest(1)...searchResDone(1)...[10 minutes
pass]...searchRequest(1)....searchResDone(1)...

and this is completely 'legal' under the LDAP RFC.

However, the LDAP dissector doesn't "see" that the MessageID has been recycled.
 When it calculates ldap.time (as used in the LDAP Service Response Time
analysis), it only "sees" the first and last uses of each Message ID.  So, in
the example above, it will report the elapsed time between the FIRST
searchRequest() and the LAST searchResDone() for each MessageID.

Needless to say, this is completely wrong.  We can't trust any Service Response
Time analysis for LDAP, nor can we reliably use ldap.time to quantify LDAP
performance for individual transactions, unless we are absolutely certain that
MessageIDs are not reused in the captured data.

You are receiving this mail because:
  • You are watching all bug changes.