Hello,
I wrote a client to make RFC 2696 (paged results) requests. My client gets results fine, yet size and cookie values are always 0, "" - this should not be the case. I tried with ldapsearch(1) and it does paging fine. Hence, it makes sense to assume that the server is OK and opaque/cookie must not be empty. At the same time, format of my ASN object is fine. I need to understand where exactly, I messed up.
In order to debug this, I added a logging LDIF and set debug to -1 any. It shows quite a lot of information, but I did not notice size and cookie values being dumped into syslog(3).
Is there a way to have separate values that go into the packets printed out? I see that there is an option for BER 0x10 and parse 0x800 as well as others.
Thank you,
Igor Shmukler
Am Tue, 18 Nov 2014 12:39:42 +0200 schrieb Igor Shmukler igor.shmukler@gmail.com:
Hello,
I wrote a client to make RFC 2696 (paged results) requests. My client gets results fine, yet size and cookie values are always 0, "" - this should not be the case. I tried with ldapsearch(1) and it does paging fine. Hence, it makes sense to assume that the server is OK and opaque/cookie must not be empty. At the same time, format of my ASN object is fine. I need to understand where exactly, I messed up.
[...]
depending on your programming language, you may run your client with strace or similar tools.
-Dieter
Dieter,
I understand that if strace(1) is available, it can be used. I want to learn how to lift the relevant debug information from the OpenLDAP server. Specially, I would love to see decoded requests and responses. It can be quite helpful in realizing whether the client author messed up the request, or the unexpected response is due to its' decoding error.
Sincerely,
Igor Shmukler
On Tue, Nov 18, 2014 at 2:01 PM, Dieter Klünter dieter@dkluenter.de wrote:
Am Tue, 18 Nov 2014 12:39:42 +0200 schrieb Igor Shmukler igor.shmukler@gmail.com:
Hello,
I wrote a client to make RFC 2696 (paged results) requests. My client gets results fine, yet size and cookie values are always 0, "" - this should not be the case. I tried with ldapsearch(1) and it does paging fine. Hence, it makes sense to assume that the server is OK and opaque/cookie must not be empty. At the same time, format of my ASN object is fine. I need to understand where exactly, I messed up.
[...]
depending on your programming language, you may run your client with strace or similar tools.
-Dieter
-- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E
On Tue, 18 Nov 2014, Igor Shmukler wrote:
Dieter,
I understand that if strace(1) is available, it can be used. I want to learn how to lift the relevant debug information from the OpenLDAP server. Specially, I would love to see decoded requests and responses. It can be quite helpful in realizing whether the client author messed up the request, or the unexpected response is due to its' decoding error.
Compile with --enable-debug (if this default was overridden) and set an appropriate olcLogLevel to get the messages. This is often accomplished in practice using the -d command line argument, rather than a permanent config change. If your server is under live load, trying this from the client (e.g. ldapsearch(1)) may be a wise approach.
See Table 6.1 in the OpenLDAP 2.4 Administrator's Guide for the available levels (please note that some levels are only relevant in slapd(8) context).
Sincerely,
Igor Shmukler
On Tue, Nov 18, 2014 at 2:01 PM, Dieter Kl?nter dieter@dkluenter.de wrote:
Am Tue, 18 Nov 2014 12:39:42 +0200 schrieb Igor Shmukler igor.shmukler@gmail.com:
Hello,
I wrote a client to make RFC 2696 (paged results) requests. My client gets results fine, yet size and cookie values are always 0, "" - this should not be the case. I tried with ldapsearch(1) and it does paging fine. Hence, it makes sense to assume that the server is OK and opaque/cookie must not be empty. At the same time, format of my ASN object is fine. I need to understand where exactly, I messed up.
[...]
depending on your programming language, you may run your client with strace or similar tools.
-Dieter
-- Dieter Kl?nter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53?37'09,95"N 10?08'02,42"E
Well, the question is what log level will print out ASNs?
On Tuesday, November 18, 2014, Aaron Richton richton@nbcs.rutgers.edu wrote:
On Tue, 18 Nov 2014, Igor Shmukler wrote:
Dieter,
I understand that if strace(1) is available, it can be used. I want to learn how to lift the relevant debug information from the OpenLDAP server. Specially, I would love to see decoded requests and responses. It can be quite helpful in realizing whether the client author messed up the request, or the unexpected response is due to its' decoding error.
Compile with --enable-debug (if this default was overridden) and set an appropriate olcLogLevel to get the messages. This is often accomplished in practice using the -d command line argument, rather than a permanent config change. If your server is under live load, trying this from the client (e.g. ldapsearch(1)) may be a wise approach.
See Table 6.1 in the OpenLDAP 2.4 Administrator's Guide for the available levels (please note that some levels are only relevant in slapd(8) context).
Sincerely,
Igor Shmukler
On Tue, Nov 18, 2014 at 2:01 PM, Dieter Kl?nter dieter@dkluenter.de wrote:
Am Tue, 18 Nov 2014 12:39:42 +0200 schrieb Igor Shmukler igor.shmukler@gmail.com:
Hello,
I wrote a client to make RFC 2696 (paged results) requests. My client gets results fine, yet size and cookie values are always 0, "" - this should not be the case. I tried with ldapsearch(1) and it does paging fine. Hence, it makes sense to assume that the server is OK and opaque/cookie must not be empty. At the same time, format of my ASN object is fine. I need to understand where exactly, I messed up.
[...]
depending on your programming language, you may run your client with strace or similar tools.
-Dieter
-- Dieter Kl?nter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53?37'09,95"N 10?08'02,42"E
On Tue, 18 Nov 2014, Igor Shmukler wrote:
Well, the question is what log level will print out ASNs?
I don't know what you're looking to "print out." OpenLDAP doesn't include an ASN.1 debugging / network analysis / etc. suite; it's not like you're going to see BNF in your syslogs. You will get hex dumps and more than a few hints.
So start big, try -d -1, see if it's what you're looking for or not...
On Tuesday, November 18, 2014, Aaron Richton richton@nbcs.rutgers.edu wrote: On Tue, 18 Nov 2014, Igor Shmukler wrote:
Dieter, I understand that if strace(1) is available, it can be used. I want to learn how to lift the relevant debug information from the OpenLDAP server. Specially, I would love to see decoded requests and responses. It can be quite helpful in realizing whether the client author messed up the request, or the unexpected response is due to its' decoding error. Compile with --enable-debug (if this default was overridden) and set an appropriate olcLogLevel to get the messages. This is often accomplished in practice using the -d command line argument, rather than a permanent config change. If your server is under live load, trying this from the client (e.g. ldapsearch(1)) may be a wise approach. See Table 6.1 in the OpenLDAP 2.4 Administrator's Guide for the available levels (please note that some levels are only relevant in slapd(8) context). Sincerely, Igor Shmukler On Tue, Nov 18, 2014 at 2:01 PM, Dieter Kl?nter <dieter@dkluenter.de> wrote: Am Tue, 18 Nov 2014 12:39:42 +0200 schrieb Igor Shmukler <igor.shmukler@gmail.com>: Hello, I wrote a client to make RFC 2696 (paged results) requests. My client gets results fine, yet size and cookie values are always 0, "" - this should not be the case. I tried with ldapsearch(1) and it does paging fine. Hence, it makes sense to assume that the server is OK and opaque/cookie must not be empty. At the same time, format of my ASN object is fine. I need to understand where exactly, I messed up. [...] depending on your programming language, you may run your client with strace or similar tools. -Dieter -- Dieter Kl?nter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53?37'09,95"N 10?08'02,42"E
Well, I raised this subject stating that -1 does not do what I need.
On Tuesday, November 18, 2014, Aaron Richton richton@nbcs.rutgers.edu wrote:
On Tue, 18 Nov 2014, Igor Shmukler wrote:
Well, the question is what log level will print out ASNs?
I don't know what you're looking to "print out." OpenLDAP doesn't include an ASN.1 debugging / network analysis / etc. suite; it's not like you're going to see BNF in your syslogs. You will get hex dumps and more than a few hints.
So start big, try -d -1, see if it's what you're looking for or not...
On Tuesday, November 18, 2014, Aaron Richton richton@nbcs.rutgers.edu
wrote: On Tue, 18 Nov 2014, Igor Shmukler wrote:
Dieter, I understand that if strace(1) is available, it can be used.I want to learn how to lift the relevant debug information from the OpenLDAP server. Specially, I would love to see decoded requests and responses. It can be quite helpful in realizing whether the client author messed up the request, or the unexpected response is due to its' decoding error.
Compile with --enable-debug (if this default was overridden) andset an appropriate olcLogLevel to get the messages. This is often accomplished in practice using the -d command line argument, rather than a permanent config change. If your server is under live load, trying this from the client (e.g. ldapsearch(1)) may be a wise approach.
See Table 6.1 in the OpenLDAP 2.4 Administrator's Guide for theavailable levels (please note that some levels are only relevant in slapd(8) context).
Sincerely, Igor Shmukler On Tue, Nov 18, 2014 at 2:01 PM, Dieter Kl?nter <dieter@dkluenter.de> wrote: Am Tue, 18 Nov 2014 12:39:42 +0200 schrieb Igor Shmukler igor.shmukler@gmail.com:
Hello, I wrote a client to make RFC 2696 (paged results)requests. My client gets results fine, yet size and cookie values are always 0, "" - this should not be the case. I tried with ldapsearch(1) and it does paging fine. Hence, it makes sense to assume that the server is OK and opaque/cookie must not be empty. At the same time, format of my ASN object is fine. I need to understand where exactly, I messed up.
[...] depending on your programming language, you may runyour client with strace or similar tools.
-Dieter -- Dieter Kl?nter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53?37'09,95"N 10?08'02,42"E
On Tue, Nov 18, 2014 at 06:59:12PM +0200, Igor Shmukler wrote:
Well, I raised this subject stating that -1 does not do what I need.
-1 prints everything that OpenLDAP has got, so you need to look elsewhere if that is not enough..
I suggest Wireshark: either use it directly to capture network traffic or run tcpdump on the LDAP server or client machine and transfer the dump file to your desktop machine for analysis. If the server or client machine has a graphical display then you can do the whole job directly with Wireshark.
Here is an invocation of tcpdump to do the capture:
tcpdump -i eno1 -w /tmp/traffic host myclient.example.com and port 389
eno1 is the name of the network interface /tmp/traffic is the dump file myclient.example.com is the name of the server if this is run on the client host or the name of the client if run on the server
Set that running and have your client code do its stuff. Break into tcpdump with control-C Copy /tmp/traffic to your desktop if necessary Open /tmp/traffic in Wireshark.
You can expand the various protocol levels to get nore detail. If you drill down into the LDAP layer you will see the search request and if you drill further you will see the paged results control, cookies etc.
Note that you will have to turn off encryption (SSL/TLS) on the LDAP session if you are using it (which you should be when you go into production).
Andrew
Hello Andrew,
Thank you for the Wireshark tip. I have solved the problem, which I had yesterday. Still, I am sure there will be a need for an analysis tool down the road. It is exactly what I wanted to find.
Sincerely,
Igor Shmukler
On Wednesday, November 19, 2014, Andrew Findlay < andrew.findlay@skills-1st.co.uk> wrote:
On Tue, Nov 18, 2014 at 06:59:12PM +0200, Igor Shmukler wrote:
Well, I raised this subject stating that -1 does not do what I need.
-1 prints everything that OpenLDAP has got, so you need to look elsewhere if that is not enough..
I suggest Wireshark: either use it directly to capture network traffic or run tcpdump on the LDAP server or client machine and transfer the dump file to your desktop machine for analysis. If the server or client machine has a graphical display then you can do the whole job directly with Wireshark.
Here is an invocation of tcpdump to do the capture:
tcpdump -i eno1 -w /tmp/traffic host myclient.example.com and port 389
eno1 is the name of the network interface /tmp/traffic is the dump file myclient.example.com is the name of the server if this is run on the client host or the name of the client if run on the server
Set that running and have your client code do its stuff. Break into tcpdump with control-C Copy /tmp/traffic to your desktop if necessary Open /tmp/traffic in Wireshark.
You can expand the various protocol levels to get nore detail. If you drill down into the LDAP layer you will see the search request and if you drill further you will see the paged results control, cookies etc.
Note that you will have to turn off encryption (SSL/TLS) on the LDAP session if you are using it (which you should be when you go into production).
Andrew
| From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 |
openldap-technical@openldap.org
-
Aaron Richton -
Andrew Findlay -
Dieter Klünter -
Igor Shmukler