Re: Status of Connectionless LDAP (cldap)

[Michael B Allen <mba2000@ioplex.com>]

On Wed, 30 May 2007 18:42:11 -0400
Michael B Allen <mba2000@ioplex.com> wrote:

> Hi,
> 
> What's the status of the client oriented connectionless code? I'm getting
> an abort. I'm tracking it down now and I'm willing to put some work into
> this so if anyone has some advice I'd appreciate it.
> 
> Mike
> 
> $ gdb cldap
> GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
> 
> (gdb) run cldap://dc1.example.com
> Starting program: /home/miallen/cldap cldap://dc1.example.com
> cldap: io.c:81: ber_write: Assertion `buf != ((void *)0)' failed.
> 
> Program received signal SIGABRT, Aborted.
> 0x0025d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> (gdb) bt
> #0  0x0025d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> #1  0x0029d7f5 in raise () from /lib/tls/libc.so.6
> #2  0x0029f199 in abort () from /lib/tls/libc.so.6
> #3  0x00296dd1 in __assert_fail () from /lib/tls/libc.so.6
> #4  0x009b0722 in ber_write () from /home/miallen/openldap/lib/liblber-2.3.so.0
> #5  0x0061926a in ldap_build_search_req () from /home/miallen/openldap/lib/libldap-2.3.so.0
> #6  0x00618ff3 in ldap_search_ext () from /home/miallen/openldap/lib/libldap-2.3.so.0
> #7  0x00619087 in ldap_search_ext_s () from /home/miallen/openldap/lib/libldap-2.3.so.0
> #8  0x0804959b in run (url=0xbff90c04 "cldap://dc1.example.com";) at cldap.c:23
> #9  0x08049767 in main (argc=0, argv=0xbff21914) at cldap.c:83
> (gdb)

Well the problem is that the ldap_search_ext function calls
ldap_build_search_req which calls

  ber_write(ber, ld->ld_options.ldo_peer, sizeof(struct sockaddr), 0);

but ldo_peer is NULL because it hasn't been connected yet.

This is best illustrated with the following call sequence outline:

ldap_search_ext
	ldap_build_search_req (tries to use ldo_peer here but ...)
	ldap_send_inital_request
		ldap_send_server_request
			ldap_new_connection
				ldap_int_open_connection
					ldap_connect_to_host calls 
						getaddrinfo
						ldap_pvt_connect (ldo_peer initialized here)

Clearly the ldap_build_search_req function is not in a good position to
know the address of the target. That would be the responsibility of the
transport layer.

So I believe the best solution is to simply skip those 4 bytes and let
one of the send functions encode the target address.

I'll prepare a patch.

Mike