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's gravatar image

wesmorgan1
3666819
accept rate: 5%


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.

link

answered 30 Mar '13, 09:30

Jaap's gravatar image

Jaap ♦
6.4k774
accept rate: 11%

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.

link

answered 30 Mar '13, 10:11

Hadriel's gravatar image

Hadriel
1.1k522
accept rate: 8%

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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "Title")
  • image?![alt text](/path/img.jpg "Title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×13
×5

Asked: 29 Mar '13, 22:40

Seen: 615 times

Last updated: 08 Apr '13, 11:31

powered by OSQA