This is our old Q&A Site. Please post any new questions and answers at

I have configured my Default profile to include a custom field for the ldap.response_in value. In Wireshark, it works great, but in tshark, the values are empty. This Windows command line returns empty lines for the 6 hits on "ldap.request || ldap.response" filter:

> tshark.exe -r ldap.pcap "ldap.bindRequest || ldap.bindResponse" -o column.format:""Response" "In", "%Cus:ldap.response_in""


asked 28 Jul '11, 08:23

ivanh's gravatar image

accept rate: 0%

edited 28 Jul '11, 15:59

helloworld's gravatar image


Tshark does one pass through the tracefile while wireshark displays packets only after analysing them all first. That's why Wireshark knows when (in the future) a response will be given to a paricular request. tshark however has no knowledge about "the future", so it does not know which packet the response will be in.

There is an undocumented option in tshark to make it do a 2-pass analysis, just like Wireshark. But I'm not sure how complete that functionality is at the moment (I have never used it myself). You can always try of course... The command line option that you have to use is "-P".

permanent link

answered 28 Jul '11, 11:18

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%

Thanks for the reply SYNbit. No joy with -P, ERROR:dfvm.c:400:???: assertion failed: (tree)

When I use the -V the values for ldap_response_in and response_to are both present. I could use this but runtimes are greatly extended and so much extra noise in the output.... ... Lightweight Directory Access Protocol LDAPMessage bindResponse(1) success messageID: 1 protocolOp: bindResponse (1) bindResponse resultCode: success (0) matchedDN: errorMessage: [Response To: 7365] [Time: 0.004628000 seconds]

(28 Jul '11, 11:25) ivanh

On close inspection of the -V output I saw that there were only Response to: values, no Response in: are present. Armed with this observation I twiddled my script and configuration and was able to obtain ldap.response_to values with single pass parsing. This makes good sense actually. We should be able to look behind at messageID to determine response_to value with only one pass.

(29 Jul '11, 07:53) ivanh
Your answer
toggle preview

Follow this question

By Email:

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



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "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

Question tags:


question asked: 28 Jul '11, 08:23

question was seen: 4,945 times

last updated: 29 Jul '11, 08:01

p​o​w​e​r​e​d by O​S​Q​A