The LDAP RFC allows Message-IDs to be reused, as long as the earlier request bearing the Message-ID has been completed.
This plays havoc with Wireshark's Service Response Time analysis for LDAP. It appears that the code simply determines the elapsed time between the first "use in query" and last "use in response" of each Message-ID, like so (capital letters are where SRT determines its measurement):
If the Message-ID has been repeated, however, the measurement is completely incorrect:
Yeah, there's a bug report to be made, but do you folks have any ideas about splitting the capture when the Message-IDs recycle? The LDAP client in question uses a range of [1..1023] for Message-IDs, so I'd like to take a capture file of a single connection and break it into chunks at each point at which a Message-ID of 1023 appears.
asked 29 Mar '13, 22:40
You can always use editcap to split up the capture files, the trick will be how to sort out where to cut. You could script processing tshark output into identifying the relevant frame numbers to cut along.
answered 30 Mar '13, 09:30
You could also use a Lua plugin to do it - create a Listener tap and keep track of the message-id's inside Lua so you can detect the number being used again, and save to separate pcap files using the Dumper object. But as Jaap said, the hard part is figuring out where to "cut" safely/accurately.
For example what should you do in this case?: "query(1022)...query(1023)...query(1)...response(1023)...response(1)...response(1022)"
Have you submitted a bug yet? Some bugs get fixed very quickly. Once fixed, it might take a while for the fix to show up in a new published release, but you can get the compiled nightly builds anytime.
answered 30 Mar '13, 10:11