201053 - PerLDAP does not work when IPv6 is enabled

Status: RESOLVED FIXED

(Directory Graveyard :: PerLDAP, defect)

Description

[Mark Smith [:mcs]]

Saul reports that PerLDAP does not work properly when IPv6 is enabled, at least
not on HP/UX 11.x. His proposed solution is to have PerLDAP use the prldap layer.

Comment 1

[Leif Hedstrom]

I've added support for prldap_install_routines() in the API.xs/API.pm modules,
and added a method to Conn.pm, installNSPR(). E.g.

   $conn->installNSPR(1);


I have no idea if this will work with IPv6 :-). I'm checking this in on the
dev-branch (devel-branch-1_4_2), and I'll hopefully finish all bug fixes for
v1.5 release before december.

Question: Are there any other prldap_  functionality that we need to support?

Comment 2

[Leif Hedstrom]

Checked in on branch.

Comment 3

[Mark Smith [:mcs]]

Leif asked:

> Question: Are there any other prldap_  functionality that we need to support?

The only thing I can think of is supporting prldap_set_session_option() so that
PerLDAP users can set the PRLDAP_OPT_IO_MAX_TIMEOUT option.  I'd say this is
"nice to have" but perhaps not essential.

Comment 4

[Leif Hedstrom]

Reopening, having issues getting it to work properly:

cc -c  -I/usr/local/csdk/include -I/usr/local/csdk/include-nspr -DDEBUGGING
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -g   -DVERSION=\"1.5\"
-DXS_VERSION=\"1.5\" -fpic "-I/export/exec/perl/lib/5.8.5/i686-linux/CORE" 
-DLDAPV3 -DUSE_SSL -DPRLDAP API.c
Running Mkbootstrap for Mozilla::LDAP::API ()
chmod 644 API.bs
rm -f blib/arch/auto/Mozilla/LDAP/API/API.so
LD_RUN_PATH="/usr/local/csdk/lib" cc  -shared -L/usr/local/lib API.o  -o
blib/arch/auto/Mozilla/LDAP/API/API.so   -L/usr/local/csdk/lib -lldap50
-lprldap50 -lssldap50 -lssl3 -lnss3 -lplc4 -lplds4 -lnspr4


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1075651872 (LWP 1231)]
0x4052162f in PR_Send (fd=0x0, buf=0x82cd3fc, amount=49, flags=0, timeout=0)
    at ../../../../pr/src/io/priometh.c:221
221             return((fd->methods->send)(fd,buf,amount,flags,timeout));
(gdb) bt
#0  0x4052162f in PR_Send (fd=0x0, buf=0x82cd3fc, amount=49, flags=0,
    timeout=0) at ../../../../pr/src/io/priometh.c:221
#1  0x404319f1 in prldap_write (s=7, buf=0x82cd3fc, len=49,
    socketarg=0x82cab78) at ldappr-io.c:218
#2  0x4042892d in ber_flush (sb=0x817dfc0, ber=0x82cd2d8, freeit=0) at io.c:414
#3  0x40415167 in nsldapi_send_ber_message (ld=0x817d4d0, sb=0x817dfc0,
    ber=0x82cd2d8, freeit=0) at request.c:399
#4  0x40414d30 in nsldapi_send_server_request (ld=0x817d4d0, ber=0x82cd2d8,
    msgid=2, parentreq=0x0, srvlist=0x0, lc=0x817e3a8, bindreqdn=0x0, bind=0)
    at request.c:333
#5  0x4041414c in nsldapi_send_initial_request (ld=0x817d4d0, msgid=2,
    msgtype=99, dn=0x82cd1b8 "o=ogre.com", ber=0x82cd2d8) at request.c:147
#6  0x4041d0f3 in nsldapi_search (ld=0x817d4d0, base=0x82cd1b8 "o=ogre.com",
    scope=2, filter=0x82cd1c8 "uid=leif", attrs=0x0, attrsonly=0,
    serverctrls=0x0, clientctrls=0x0, timelimit=-1, sizelimit=-1,
    msgidp=0xbfffedfc) at search.c:232
#7  0x4041e31f in nsldapi_search_s (ld=0x817d4d0, base=0x82cd1b8 "o=ogre.com",
    scope=2, filter=0x82cd1c8 "uid=leif", attrs=0x0, attrsonly=0,
    serverctrls=0x0, clientctrls=0x0, localtimeoutp=0x0, timelimit=-1,
    sizelimit=-1, res=0xbfffee94) at search.c:995
#8  0x4041e255 in ldap_search_s (ld=0x817d4d0, base=0x82cd1b8 "o=ogre.com",
    scope=2, filter=0x82cd1c8 "uid=leif", attrs=0x0, attrsonly=0,
    res=0xbfffee94) at search.c:938
#9  0x403ebf98 in XS_Mozilla__LDAP__API_ldap_search_s (cv=0x8172af8)
    at API.c:2754
#10 0x080ce17d in Perl_pp_entersub () at pp_hot.c:2857
#11 0x080b0513 in Perl_runops_debug () at dump.c:1442
#12 0x080624d5 in S_run_body (oldscope=1) at perl.c:1924
#13 0x08062063 in perl_run (my_perl=0x816e008) at perl.c:1843
#14 0x0805e555 in main (argc=7, argv=0xbffff124, env=0xbffff144)
    at perlmain.c:86

Comment 5

[Leif Hedstrom]

Finally fixed this, it's an inherit problem with some assumptions made in the
Conn object. I thought I could do
   ldap_bind_s(...);
   .
   .
   ldap_unbind_s(...);
   prldap_install_routines(...);
   ldap_bind_s(...);


but that doesn't seem to work. So, if the user install the NSPR layer after
creating the Conn object, I simply discard the old LDAP* struct, and create a
new one. This seems to work, even though it's ugly.

To avoid this, I added a new option to the ctor for the Conn object, so you can
now call it like:

   $conn = new Mozilla::LDAP::Conn(usenspr => <shared_flag>, ...);

Or, if you wish to enable NSPR for all new Conn objects, call the class method like:

   Mozilla::LDAP::Conn->installNSPR(<shared_flag>);

The shared_flag is either 0 or 1. The only config option supported is the
timeout, e.g. 

   $conn->setNSPRTimeout(100);