| 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 |
[email protected]
|
| Reporter |
[email protected]
|
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.