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: Ideas? asked 28 Jul '11, 08:23  ivanh edited 28 Jul '11, 15:59  helloworld |
One Answer:
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". answered 28 Jul '11, 11:18  SYN-bit ♦♦ |
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]
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.