I'm troubleshooting an AD/LDAP integrated application. If I start up Wireshark prior to starting the application/service (i.e. before the bind takes place) then my capture file is perfectly readable. However if a preexisting ldap/389 connection exists to the server, the LDAP packets show as LDAP, but the INFO field is empty. If I look in the "packet bytes" window I can see the LDAP traffic. It is unencrypted/clear text but it is not being decoded into an LDAPMessage so it is incredibly difficult to read - especially when the need exists to look at hundreds of these. The problem is that I cannot just restart the service to get a new bind because the issue I'm looking into is always resolved on service restart. I'm trying to understand what the limitation of Wireshark is in properly decoding these packets. Since I can see the LDAP data in the bytes, and because wireshark seemingly knows they are LDAP, why can't they be constructed properly? Is there anyway around this? p.s. the traffic in question is also SASL GSS-API LDAP thanks asked 22 Apr '15, 13:13  BenH |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
can you show the effect in a pcap file? If so, please upload the file somewhere (google drive, dropbox, cloudshark.org) and post the link here.
https://www.cloudshark.org/captures/1ee3a895c06f with-bind - shows a capture from the startup of the service, which includes the bind to ldap. everything looks good here.
https://www.cloudshark.org/captures/e1e92a699be9 pre-established - shows a capture starting after the bind has been completed. Note that the ldap packets 1-6 are basically identical to packets 8-13 from the with-bind capture.
If you drill down packet #9 in with-bind and packet #1 in pre-established all the way down to the LDAP data you'll see the byte data is pretty much identical except in the with-bind it's decoded and in the pre-established it is not. You can see my comparison here:
http://oi60.tinypic.com/dhd2cl.jpg
thanks