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): "QUERY(1)...query(2)...response(2)...RESPONSE(1)" If the Message-ID has been repeated, however, the measurement is completely incorrect: "QUERY(1)......response(1).......query(1).....RESPONSE(1)" 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. Any suggestions? asked 29 Mar '13, 22:40  wesmorgan1 |
2 Answers:
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  Jaap ♦ Yeah, this is the approach I'll probably take. I found a tool (SplitCap) that can separate a large capture file into per-conversation files; from there, a quick shell script will grab frame numbers from tshark output and feed them to editcap. I'm just really not looking forward to running SRT analyses on 300 files instead of 3-5 files. laugh (30 Mar '13, 11:24) wesmorgan1 |
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  Hadriel I have not submitted a bug report; I have to get this analysis finished before I go figure out the bug reporting tool. laugh (30 Mar '13, 11:25) wesmorgan1 For the immediate need (i.e. the gigabytes of capture data I have to analyze), I'm going to add a fudge factor for the overlap problem you described... (30 Mar '13, 16:11) wesmorgan1 |
Bug report filed - https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8570